Building a Security Framework in a Compliance-Driven World
Depending on the industry an organization is in, there are a multitude of specific, acronym-heavy rules, regulations, and frameworks which must be adhered to, especially for industries with extremely sensitive and valuable data, including healthcare, banking, and energy. For many years, these compliance-first frameworks – HIPPA for healthcare, PCI-DSS for credit card handling, and NERC-CIP for energy companies, to name a few – were the structure around which IT leaders managed their security programs. To further complicate things, there are multiple compliance-based frameworks that overlap and even others that are specific to the states in which an organization does business, like CCPA. A common example of cyber security compliance? Once a year (typically) organizations are required to have an outside, third party evaluate its programs. Voilà! An organization is secure, right? Not always.
In my opinion, building your security program around a framework for compliance, ensures an organization is compliant, but doesn’t necessarily make it secure. In fact, if you’re simply implementing a security strategy to check a box, it’s likely that your systems are vulnerable to cyber adversaries. While security is foundational in these compliance-based frameworks, historically it was deemphasized for a period of time. But things are changing – specifically, the way we think about security is shifting away from a compliance-first mindset. Big data breaches got the attention of Boards of Directors from a financial (read: fines, lawsuits) and reputational loss standpoint. From a technology standpoint, there’s no longer an inside and outside of the organization and just defending perimeters with firewalls is no longer adequate. And, one more example, with a move away from a waterfall release of applications to a more agile development philosophy, it makes business sense to elevate the frequency of vulnerability assessments, even moving to a continuous, ongoing monitoring of internet-facing attack landscapes to more adequately protect against unauthorized access to an organization’s intellectual property.
Organizations that have a more mature technology footprint are surely interested in doing everything they possibly can to find and fix vulnerabilities. And even in a mature scenario, there’s ample opportunity to put in an action-based framework that ties up to an organization’s controls and security framework. Consider this: the world’s leading research organization, Gartner, found that between 2014-2018 approximately 41 percent of clients had either not selected a framework or had developed their own ad hoc framework. It goes on to show that failure to select any framework and/or build one from scratch can lead to security programs that:
- Have critical control gaps and therefore don’t address current and emerging threats in line with stakeholder expectations.
- Place undue burden on technical and security teams.
- Waste precious funding on security controls that don’t move the needle on the organization’s risk profile.
How can we begin to administer a security-based framework? Quite simply, just begin. It doesn’t have to be perfect from the get-go. Consider it a work in progress. After all, the threat actors, technology assets, and detective controls are constantly changing. Thus, you will need to constantly change and adapt your continuous, always-on security and vulnerability management program. Here are some best practices to help you begin implementing your security-based framework changeover.
- Evaluate the landscape: Determine whether there has been a security framework or controls catalog developed for your specific industry sector. The NIST Cybersecurity Framework is a good place to start. But what happens when there is no industry-specific or government-mandated security framework and control catalog? In this case, security capability maturity and team capacity and capability become the key inputs in selecting your security control framework and control catalog. (Source: Gartner)
- Engage with organizational leadership outside of technology: Develop a scrum planning team with legal, risk, and front-line business unit representatives to help identify discrete regulatory or legislative obligations that need consideration.
- Audit your internal and external environment: Identify the contextual factors that could influence your selection of security framework and control.
- Invest in your people: Admit to technology fatigue and that some significant investments aren’t optimized to meet set objectives or are redundant. Instead, invest in a people-first, pentesting team that can approach security from the eyes of an attacker.
- Develop a plan based on continuous improvement: Combine manual and automated pentesting to produce real-time, actionable results, allowing security teams to remediate vulnerabilities faster, better understand their security posture, and perform more comprehensive testing throughout the year.
Remember: Just because an organization’s cyber security program is compliant, doesn’t mean it is secure. If an organization approaches its security programs from a security-first mindset, most likely it will comply with the necessary compliance rules and regulations. I see compliance as a subset of security, not the other way around.
Want more? Read “Challenges & Keys to Success for Today’s CISO” from the Former CISO at the CIA, Robert Bigman.
Explore more blog posts
Part 1: Ready for Red Teaming? Intelligence-Driven Planning for Effective Scenarios
Take time for dedicated planning and evaluation ahead of red team testing to prepare your organisation for effective red team exercises.
The Strategic Value of Platformization for Proactive Security
Read about NetSPI’s latest Platform milestone, enabling continuous threat exposure management (CTEM) with consolidated proactive security solutions.
Backdooring Azure Automation Account Packages and Runtime Environments
Azure Automation Accounts can allow an attacker to persist in the associated packages that support runbooks. Learn how attackers can maintain access to an Automation Account.