Non-Security Things That Can Sink A Security Program
Don’t Look Up
Security professionals have a tendency to take ownership of lots of stuff. We carry the fate of our companies in our hands, and take the responsibility for protecting our organizations to heart. This feeling of accountability and ownership is an common reason why people come into the profession, and why they stay — we’re on a mission to save non-security people from themselves.
Sometimes, in the fog of cyber war, it’s easy to overlook the reality that we are not working in a vacuum. That the environments in which we work, over which we have limited control, have as much to do with the success of our security programs as any decision we make or function we own.
How do you measure the success of a security program? Enabling the business, managing risk, and operating efficiently are the basis of a good security program. It’s not enough to have “no breaches”, that may indicate great management, or great luck (or lack of visibility). It’s not enough to have great relationships with stakeholders (although that can help), because being well-liked doesn’t mean you’re making good security decisions. It’s not just about being “efficient”, if being efficient means you miss a critical security indicator or have high staff burnout. It’s not about being compliant with rules and regulations, because we all know that while being compliant helps, it’s not enough to really get to a risk-based, business-enabling security program. As a leader, it’s not about how many talks you give, awards you win, or social media followers you have.
Definitely, take the time to create a security strategy. Consider your threats, vulnerabilities, likelihoods, compliance requirements, business objectives, etc., etc. Eliminate single points of failure in your team, make friends with stakeholders, and generally Do All The Things.
And Yet…
Even if you do everything right for your team, there are some things outside your control that can sink your program before you even start. So as you think about your strategy, you have to also evaluate those other things, and if they are not working as you expect, you will need to consider whether you should do anything to help them get better — because it will be in your shared interest to make them better. Consider:
Asset Management
We’ve all heard it before, right?
You cannot protect what you don’t know about
I haven’t encountered a security leader who is directly responsible for asset management, but every single one will include asset management and inventory as a foundational element of their program (the “Identify” function of NIST). Asset management used to be in place as a financial measure (do we know the book value of the things we have?) and an IT operations measure (do we know what we’ve committed to support?), and typically security requirements have been tacked on, begrudgingly, at the end of the requirements list.
These days, security people have to know about assets that the company doesn’t own, and doesn’t manage, because our data is there (BYOD, cloud services, etc.) and we are responsible for our data and the systems the data is on. What would your CMDB look like if it measured “things that hold/transmit data” rather than “assets we own”? Security folks don’t only need to know what assets hold data, but also how they are configured, what libraries they use, what dependencies they have. The rise of SBOMs are indicative of this ever-expanding problem.
Technology Stack
Whatever adds to complexity in technology being used ultimately degrades the effectiveness of a security program. Talk to security leaders about pain points, and it will look something like:
- Old stuff (beyond vendor support)
- Distributed IT management (many decision makers)
- Lack of technology standards (aka user choice)
- Bleeding Edge/Customer Promises(IT and sales leaders doing new things without regard to operational integration)
The thing all these have in common is that the organization, outside security leadership, is allowing these things to occur. Sometimes, there are good reasons for it, sometimes there really isn’t. The reality for the security leader is that the more of these problems there are in an environment, the higher the likelihood that no matter how good the security program, bad stuff is likely to happen. Having a current, integrated, standards-based technology stack leads to happy security programs. Anything else is counter-productive to security efforts.
Identity
Identity, particularly of people and their roles, is a tricky one for security. There are usually some pieces of identity that functionally sit in the security team: authentication, identity management, or privileged account management. Often, there are pieces that sit in IT (active directory and other parts of authorization, identity systems interfaces, etc.). Then, there are the pieces that sit in business operations — account onboarding, role definition and authorizations, recertifications, offboarding.
By its nature, identity management is distributed between many organizational functions, and all that distribution leaves room for errors, misunderstandings, and misalignments. Yet identity is a foundational element for security.
If you cannot know that the person is who they say they are, with appropriate access based on what they do, with appropriate training and skill for their level of responsibility (particularly managers), then any control that uses identity (aka all of them) will be weak.
Security folks try to manage this using things like User Behavioral Analytics (UBA) solutions — but none of them cover the entire lifecycle (and even-post life events) that occur in the real world. There needs to be a consolidated identity strategy across the entire organization; rarely is this done.
Organizational Governance
There are many people and departments in an organization who play a role in keeping the organization working well, and security leaders spend a lot of time working with these major stakeholders to ensure proper security alignment. Individually, these groups (finance, legal, purchasing, c-suite, board, etc. etc.) can help or hurt the security function. But when the interplay between these groups is broken it can completely scuttle security (and the rest of the business).
- There needs to be an organizational vision and strategy that everyone understands and follows. If people are going in multiple directions without coordinating leadership, security has to fill in the gaps in technology, people and process.
- There needs to be integrated risk management, so all the benefits of a strategy are evaluated alongside all the risks (not just security risks) of the same strategy. If leadership is only evaluating the upside of an idea, without understanding the downside, they are operating without full information, and security/legal/others must clean up the mess afterwards, usually without funding.
- There needs to be accountability from the board on down, and trust from the front lines on up. It needs to be clearly communicated when the business is working well, and when it is not, without blame or retribution. Otherwise, there is lack of transparency and if security doesn’t know about it, they cannot help protect it.
- Processes need to be effective and constantly optimized. So many security events happen because of poor non-security process. Bad processes anywhere in a business will undermine any security efforts.
So what is a security leader to do?
First, before you even take the job, ask about these aspects: asset management, identity strategy, technology stack, inter-department governance. No one will be perfect, but at least you’ll know what you’re getting yourself into.
Second, consider if there are ways for you to take more direct accountability for some of these. Not everything will be solved by ownership, but a large portion of it will. Even if functional ownership isn’t possible, consider funding people to work in those areas. Your indirect influence will be invaluable.
Third, make friends with people in those areas. They will be your key stakeholders as much as the c-suite or the board. Know who does asset management, know who runs parts of identity management, know who coordinates the enterprise risk management function. Evaluate their competencies, and help them where they are weak (and reward them where they are strong).
Consider empowering your team (if you have one) to also bolster those other areas, with their support and their solutions. These other areas are not only important to security, they are often themselves under funded and under appreciated. Buddy up your team with theirs — it will help everyone.
Most of all, remember that you don’t operate in a vacuum. Just as you can’t be completely responsible for a security event at your company, you also can’t take credit for a strong program without the support of these other areas. Think broadly, and think big.
Your security program will thank you.
