In my previous post, “Mastering Cybersecurity Maturity: A Comprehensive Guide to Assessing Your Defenses,” I spoke about how all organizations should be focused not just on whether they have a given compliance framework control or control family in place, but also on gauging to what degree they have implemented the control from a cybersecurity maturity model. Rather than repeat some of the basic concepts from that guide, here we will assume that you have accepted the observation that improving your security posture requires self-reflection on your infosec program’s strengths and weaknesses in terms of automation, optimization, and capability. So the next question that naturally comes to mind is to think about where to attempt improvements and why.
A Little History
The concept of a cybersecurity maturity model is an extension of the Capability Maturity Model (CMM) developed in the 1980s after a study of data collected from organizations that contracted with the U.S. Department of Defense. Primarily concerned with the quality of software development processes, the idea of a capability model can easily be extended to other areas of work where process optimization is a desired outcome. If one takes the perspective that security vulnerabilities and misconfigurations are just another form of software bugs, then it is simply a matter of writing tickets to address these bugs, no? Not exactly. Having no open security findings after performing a code scan of an application software repository does not mean that you are secure or that you are not at risk. A good pentest will often reveal business logic flaws in an application process that are not based on exploitable software packages and libraries that make up the application or API. The cybersecurity maturity model helps teams take account of components to an infrastructure that are not just lines of code.
From Nothing to Something
In the film “The Sound of Music” there is a lyric that goes:
Let’s start at the very beginning
A very good place to start…
In performing security assessments for companies both large and small, I have found that starting from scratch is helpful for several reasons. With startups it is often the case that they will score a “0” for various security controls and processes or policies. Nothing exists on paper and nothing exists as a technical control. A perfect example of this is the principle of least privilege and the implementation of role-based access controls (RBAC). In the early days of a startup, the need for speed and the ability to enable self-service problem-solving winds up with a permissions scheme of “all or nothing.” Either you have full admin on the cloud infrastructure, or you have no access at all. If left this way for too long, the issue accretes additional risk over time and becomes technical debt.
Conversely, the pathology that emerges within a long-running organization or enterprise is credential bloat. Department names change slowly over time due to restructuring efforts along with the corresponding permissions for file shares and access to service accounts, databases and systems. A group of devops engineers might be temporarily spun off from the main team to focus on quality control issues in the release engineering function. They are given additional permissions and group memberships in Active Directory, for example, and when the initiative is completed, these permissions are seldom removed or pulled back.
There is, and this has been learned from first-hand experience in such organizations, a technical term called “token bloat” for Windows infrastructures. Token Bloat occurs when you are a member of too many groups in Active Directory. At somewhere around 125 groups, your Kerberos token size reaches 64kb in size and causes authentication problems. In these situations, it can often be easier and more efficient to “pave over” the existing infrastructure and launch an entirely new effort which is, in a sense, starting from scratch as well. “Fixing” the problem and trying to trace out the dependencies and inheritance of permissions on objects and files can prove to be a painful and prolonged process that frequently involves shooting yourself in the foot, as they say. Repeatedly. Furthermore, some of the original reasons for various permissions and group membership may no longer be relevant, so sleuthing it out is of little value to the business.
Maturity Levels
With some of the proverbial “low hanging fruit” taken care of by introducing a technical control and the corresponding policy documentation where none had previously existed, we’re ready to explore in a bit more depth the five cybersecurity maturity model levels of Hyver, CYE’s optimized cyber risk quantification platform. I’ll use the remainder of this blog post to provide a few more stories and anecdotes that will serve to illustrate the points and characteristics of each maturity level.
Level 1: Initial
Unstructured security practices: Cybersecurity processes are ad hoc and disorganized, lacking standardized controls. For controls addressing asset management, a company with a Level 1 maturity might have a spreadsheet that contains some (but not all) of the serial numbers of laptops and servers that the company owns. But the spreadsheet is not kept up to date and is not complete, so even the information that it does contain may very well be incorrect as to who is the current owner of a device, for example.
Limited threat visibility: There’s a minimal understanding of potential cybersecurity threats, and responses are reactive. If an organization does not have an accurate or complete inventory of hardware, then the software packages and versions installed on those devices will also be incomplete or partial. How can the infosec team perform an impact assessment or risk analysis of a Zoom vulnerability, for example, if they do not know how many devices have Zoom installed or which version of the software is installed?
Level 2: Developing
Basic security management: Basic cybersecurity management practices are introduced, including incident response plans. Not all activity is reactive and some processes are documented and repeatable (though not automated). A Level 2 maturity for identity and access management controls, for example, would include performing a user rights audit once or twice per year to ensure that permissions are “right-sized” for each user.
Risk management: Initial steps are taken to identify and manage cybersecurity risks. The emphasis is on securing assets and data. Core projects to improve cybersecurity are budgeted and tracked towards execution, such as deploying a password vault or implementing SSO (or expanding its use to third-party platforms that support SSO). Before progressing to Level 3, it makes sense to make sure there are no “zero maturity” areas of work with regard to the observations from an external risk assessment (normally performed against the NIST CSF).
Level 3: Defined
Standardized security processes: Well-defined and documented cybersecurity processes are implemented across the organization. At this level, the burden of performing a SOC2 audit is greatly reduced because there are artifacts available to the auditors that clearly demonstrate that a process is in place which is followed and which meets “reasonable security” practices.
Comprehensive security measures: Comprehensive security measures are put in place, covering areas such as access control, encryption, and vulnerability management. A combination of documentation and cybersecurity technique are present with Level 3 that makes it easy to onboard new hires. This is because there are both technical controls in place with some elements of automation as well as managerial oversight and process to ensure that new software developments and products for the company are discussed with the security team before they are deployed into production. The SDLC (Software Development Life Cycle) will have components that perform code scanning or vulnerability management in a manner that encourages earlier identification of issues and exposure to risk.
Level 4: Managed
Quantitative risk management: At this level, the effectiveness of technical systems is measured and evaluated, policy compliance is measured and enforced, and procedural effectiveness is monitored. Cybersecurity processes are quantitatively managed using metrics and statistical techniques. Increased sophistication of tooling allows for threshold-based monitoring, such as adding a firewall analyzer, and code coverage for repository scanning.
Continuous improvement in security: Constantly evolving and improving cybersecurity practices based on quantitative analysis and feedback. Level 4 will almost certainly introduce a VDP (Vulnerability Disclosure Program) with a company that provides continuous penetration testing and assessment of asset and software risk. Additionally, a bug bounty program might also be funded that rewards those who report issues to the security team for their efforts, demonstrating to the market that the company takes security seriously and is willing to share some remediations of exposures as a means of building trust and transparency.
Level 5: Optimizing
Innovative and improved cybersecurity practices: Emphasis on innovative cybersecurity solutions and practices to stay ahead of emerging threats. One example of an innovative practice is the formation of a threat intelligence capability (either in-house or outsourced) which proactively engages with ISACs (Information Sharing and Analysis Centers) to participate in sharing TTPs and IOCs with industry partners and also competitors. Another example would be to have a deception program that is responsible for operating canary tokens and honey pots in order to receive advanced warning of aggressive security posture probing and testing by threat actors.
Organizational cybersecurity learning: The organization learns from cybersecurity incidents, adapting and optimizing security measures for continuous enhancement. This would extend from its own infrastructure and services to also include that of its third- and fourth-party service providers and vendors to mitigate supply chain attacks and breach risks. Although not often achieved even by well-funded and well-managed security programs, Level 5 maturity does take place and is not impossible to achieve.
(Not) the End
Progressing along this path of cybersecurity maturity is what is meant by the phrase “continuous improvement” and is a goal worthy of pursuing. Hopefully you have learned enough to begin your journey and have realized that it’s not the destination that matters, it is the journey itself that brings the benefits and improvements. Benefits in the form of tooling and process improvement, but also benefits to the security culture and mindset of your organization. The final level of cybersecurity maturity is intentionally self-referential almost like a zen koan. It is a riddle that has no single answer and no set solution space. You are free to interpret what your Level 5 might look like and it will depend on your industry, your company’s DNA, and the “connect the dots later” point of view that Steve Jobs famously referred to in his Stanford University 2005 commencement speech.
The cybersecurity maturity model is a tool that you can wield to help set clear goals for your organization and make those goals quantifiable. You can track your progress across hundreds of controls, each of which can be assessed on this model and understood in terms of what capabilities you wish to obtain. So I entreat you to go forth and benchmark!
Learn more about Hyver’s cybersecurity maturity assessment here.
