Looking for something else?
The weight of compliance on businesses has never been higher. The changing landscape of regulatory requirements, limited personnel budgets, non-comprehensive solutions, and increasing consulting costs associated with compliance audits has financially debilitated many companies, both large and small, across multiple industries. Without recognizing the inception of most regulatory requirements, some CISOs may think that the alphabet soup of compliance-affiliated acronyms has served no one; it has simply deepened the financial pockets of security consultants and compliance auditors.
As a result, the perception of the value of compliance has taken a toll, without diminishing its need. We are left with a broken belief system of what compliance actually brings to organizations beyond a Record of Compliance or Authority to Operate (ATO). So, what went wrong, and how do security professionals begin to rethink compliance? It all hinges on execution.
Corporate compliance initiatives largely originate from within internal compliance groups, third-party consulting firms vying for some business, or large clients with regulatory risks that now become your organization’s regulatory risks. Using everything from scare tactics to grossly exaggerated business opportunities that begin with some level of compliance certification or accreditation, companies have been spending big money on compliance. Over time, addressing compliance challenges has been seen as the “necessary evils” in a company’s business plan or objectives. This perception of addressing compliance requires a complete makeover—beginning with workflow.
Executive leadership and compliance management officials must consider a new workflow strategy for compliance. Rather than making compliance initiatives post-mortem to other workflows, such as Software Development Lifecycle (SDLC) processes, new vendor relationships, or services where data security is impacted—compliance should be baked-in.
The existing model of compliance audits provides absolutely no strategic value other than simply achieving a given compliance objective. It is adversarial by design, invasive to subject matter experts’ full-time roles and responsibilities, and subject to a higher degree of subjectivity. Auditors have to formulate their observations in isolation and perform the dance of validation, typically over email, to arrive at an acceptable level of control observations. Most importantly, compliance audits are largely focused on control gap analyses, and auditors are forced into a check-box mentality. Clients quickly perceive these types of assessments, or control audits, as tedious and wasteful; and hence, the poor perception of compliance snowballs further.
Redefining the perception around compliance begins with coming to terms with a common denominator of intent around each compliance objective. Simply said, each regulatory requirement stems from the intent to ensure greater guidance and oversight around data integrity, system availability, and confidentiality of non-public data. With this in mind, compliance efforts can become re-defined and re-integrated into a workflow that is more collaborative in execution and strategic in nature. With a prescribed set of compliance goggles—that are not jaded—organizations can adopt the new perception and address regulatory compliance issues upfront across various enterprise workflows. These same workflows already have functional requirements that make up how changes are ultimately approved and implemented; similarly, a catalog of compliance requirements can be addressed at key checkpoints of various processes in change control, access control, network operations, security monitoring, asset management, and system or software development.
By operationalizing compliance to a suite of “living” requirements, they quickly become indoctrinated into each operational area and addressed in a completely different manner, rather than at the tail-end of a process when regulatory checklists are presented. At the end of today’s dysfunctional process, there is a potential for changes to become undone; application or system functionality to become revoked; and network or logical rules that need tightening; as a result of foregone compliance checks that were not addressed earlier.
Compliance integration via risk-centric threat modeling
Re-architecting how and when compliance efforts get achieved is a big mind-shift for many Fortune 500 organizations, but the small business player is typically hungry to know ways in which greater integration can foster a more streamlined process. A key way that compliance efforts fall into the operational fold is via risk-centric methodologies on threat modeling. Although threat modeling’s objectives are primarily focused on threat enumeration for improved strategic countermeasure development, the first phase of the seven-stage Process for Attack Simulation and Threat Analysis (PASTA) framework identifies business objectives, and security and compliance requirements, so that they do not live apart from threat modeling methodology. Ironically, small-to-medium enterprises involved in Stage 2 of PASTA, which defines the technical scope, are largely the same audience as those remediating compliance gaps in a traditional audit workflow.
Stage 1 of PASTA is about defining business objectives. Achieving compliance for some organizations is sometimes a central business objective; for example, those seeking to obtain a government ATO in FISMA. For most organizations, however, compliance with certain regulations plays a key variable, but it is not an all-encompassing business equation. In either case, business objectives can become impacted by regulatory compliance challenges for firms, both large and small.
Defining a workflow to streamline compliance efforts and achieve greater integration is where tomorrow’s compliance ingenuities can take place. By simply airing out upfront, some of the key regulatory challenges that may impede a product launch, merger and acquisition, or service delivery, the perception and ability to incorporate regulatory requirements are drastically improved. Stage 1 of PASTA provides an opportune time for CISOs, business managers, and compliance analysts, among others, to truly understand how regulatory requirements in NERC CIP, PCI-DSS, or HIPAA HiTECH impact proposed changes for the business in terms of services or product deliveries. Compliance requirements can now be collaboratively discussed in terms of viability, time for implementation, and even non-compliant actions, if such routes are unanimously supported and documented by the collective roundtable.
This approach is a sharp contrast to the “us versus them” approach that inevitably occurs when compliance seeks to evaluate controls after the business and technology groups are already celebrating a “finished” process or product. By simply integrating compliance efforts earlier in the process, the effects are vastly improved in terms of perception and execution.
Threat modeling via PASTA provides the medium for this integration to take place, particularly in Stage 1 (Define Business Objectives) of this risk-centric threat modeling methodology. With compliance requirements revealed as part of this phase, the threat model for a given application, system, or service can continue to evolve its main purpose of key objectives that are germane to similar models such as defining the attack surface, attack enumeration and probabilistic analysis, and countermeasure (or control) development. Without delving into these more technical areas, the key advantage now is a process that has become more tightly integrated to the business, technology areas, and with security.
Serving compliance on PASTA
Success in business is all about execution and timing. This is equally true for the underlying legs that affect a business on the metaphorical table of compliance. By abiding by a repeatable framework on how and when compliance awareness, measurement, and gap analysis takes place, traditional remediation groups now become stakeholders that are able to (a) understand the breadth and depth of the regulatory requirements and (b) factor in the controls during the SDLC process (for new product development efforts) or change control procedures. Similar to how IT has to present functional requirements at different levels (infrastructure, system and software), stakeholders in Stage 1 of the PASTA process now transform their perception of remediation lists into functional compliance requirements—a concept that is more palatable for many technical and business stakeholders to understand. As such, redefining the manner in which compliance is delivered within the enterprise can be revolutionary and synergistic if given the right framework. PASTA provides an option to realizing this new and effective form of executing compliance initiatives within the organization.
Compliance is long overdue for a strategic overhaul that doesn’t involve product-based initiatives and next generation Web portals. Working towards a more foundational and integrated approach that aligns compliance with technology, security, and business objectives is a step in the right direction. Today’s tail-end approach of after-thought compliance efforts only isolates compliance into an adversarial corner. Leveraging a risk-centric threat modeling methodology such as PASTA can encourage compliance activities to take place alongside SDLC phases or existing change control procedures. This presents a new compliance strategy that redefines perception, gives life to more collaborative compliance efforts, and helps ensure that compliance charters do not become undermined, but instead help balance unique technology and security objectives into a streamlined business goal.
About the author:
Tony UcedaVelez, CISM, CISA, GSEC, CRISC is a managing partner at VerSprite. Send comments on this column to firstname.lastname@example.org.