In Part I of this blog series, we introduced information modeling as a method to reduce compliance gaps. In this blog, we create a master model of protection based on the business model of a fictitious company called Eclipse Cloud Services (ECS). The master protection model forms the basis of contextualizing access to the infrastructure, compliance requirements, security specifications, threat landscape, and capabilities.
We discussed previously that ECS is a cloud service provider (CSP) whose key activities are offering Software as a Service (SaaS) and Platform as a Service (PaaS). Beyond the former components of value that comprise ECS’s business model are those that support deductive logic. That is, based on the characteristics of the components, you may derive a reasonable conclusion. The deductive components of any organization’s business model are: Value Proposition, Customer Segments, Key Activities, Key Resources, and Key Partners.
Customer Segments: Compliance Underpinnings
Understanding the customer segment of your organization is critical to developing a strategy that ensures regulatory compliance. Many compliance mandates are based on the protection of consumer data such as:
- Children’s Online Privacy Protection Rule (COPPA): protects the information of children under the age of 13
- Health Insurance Portability and Accountability Act (HIPAA): protects patient healthcare information (PHI)
- IRS 1075: protects federal tax returns and return information
- Payment Card Industry Data Security Standard (PCI DSS): protects credit card information
The characteristics of a customer segment enable one to determine which industry verticals are traversed, along with key characteristics comprising the data sets stored, processed, and transmitted by your business. ECS’s industry verticals are education, federal government, state government and e-commerce. Therefore, one can reasonably conclude they must minimally comply with federal and state mandates. Additionally, one may infer the need to verify privacy laws related to minors. Generally, it can also be assumed that consideration of consumer payment protection is also in scope.
Several standards bodies have provided consolidation across the most prevailing statutes, standards, and frameworks of information security. Thus far, the most comprehensive aggregations have been performed by the Health Information Trust Alliance (HITRUST)1 and Cloud Security Alliance (CSA).2 Free downloads are available to support compliance profiling.
ECS’s compliance profile will include, at a minimum, Children’s Online Privacy Protection Act (COPPA), Federal Risk and Authorization Management Program (FedRAMP), Federal Information Security Management Act (FISMA), Payment Card Industry Data Security Standard (PCI DSS), and state privacy laws. ECS’s compliance profile could become even more complex if its ecommerce offerings store healthcare information or provide services internationally. Once compliance requirements are verified, suitable control frameworks and standard specifications along with assessment methodologies are selected.
Enablers of Compliance: Standards & Frameworks
Where statutes mandate what we must protect, security standards and frameworks tell us the how (for example, specifications), and compliance methodologies provide ongoing effectiveness assurance. Standards and frameworks provide cross-cutting specifications that one might tailor to the technology strategy of their organization. At times, it has been assumed all controls detailed must be applied; what is expected is a minimum of controls that must be applied and maintained to meet mandate requirements.
Enough of the standards can be designed modularly using the control family as the common grouping. The manner in which controls are applied is at the discretion of the organization, as long as the controls meet mandates. An established framework such as HITRUST may be used, or an organization can create a proprietary framework by blending ISO and NIST standards. There are instances when organizations must consider at least two mandates, of which one is more stringent. When such circumstances arise, jurisdictional prudence applies. That is, federal mandates set the “floor” (baseline) with locale-specific requirements taking precedence when they are more stringent. There are also instances in which a contractual agreement may specify a more stringent requirement. In such cases, those requirements take precedence over federal and locale-specific (for example, state) mandates. Finally, when an organization itself has more stringent mandates, those take precedence.
Control effectiveness is assessed continuously using either a proprietary methodology associated with a specific mandate, such as Sarbanes-Oxley (SOX), or through a prevailing standards body such as Control Objectives for Information and Related Technology (COBIT) or American Institute of Certified Public Accountants (AICPA). Realistically, expect multiple assessment methodologies, because different data types carry different levels of risk that result in different types and degrees of control application.
Key Activities and Key Partners: Your Threat Landscape
Characteristics derived from the key activities and partners of your business model form the threat landscape, but how? First, the key activities provide insight into the services you provide, thereby allowing one to reasonably assume the constructs of the underlying technology infrastructure required to support it. ECS offers cloud service models of SaaS and PaaS. Because it offers the service to multiple customers from common verticals, one can infer its solutions are multi-tenant. The zoning model is envisioned based on a Service-Oriented Architecture (SOA). Because presentation services must exist for the SaaS customers to access their solution, one can infer that customer data will be stored in a database, which means there are likely application services as well. The security and infrastructure zones support and protect the application and data zones.
Once you’ve contextualized your SOA implementation, you can align the technology stack based on the service the technology provides. Platforms that host applications or databases along with appliances that provide infrastructure (for example, routers, switches) and security services (firewalls or IDS/IPS) become your technology stack inclusive of boundary environments technologies from which they are deployed.
Next, identify those key partners that must have trusted access to your infrastructure and which partners will provide you trusted access to their infrastructures. The information systems and communication channels providing access present opportunities for access and must be factored in as part of the threat landscape.
Your hosting model, service architecture model, and partners with trusted access—along with your technology stack—compose the threat landscape.
Rationalizing Capabilities
Your organization's threat landscape is protected by capabilities. Capabilities are realized outcomes of combining people, process, and technology (PPT). Examples include the Incident Response team, user provisioning and deprovisioning, e-discovery, and Security Information Event Monitor (SIEM). Rationalizing PPT ensures you recruit the right talent, build value-added processes, and select technology that supports the organization’s business model.
Visualizing the Master Model of Protection
Based on the characteristics of the business model we derived, we develop our master model against which we can model protection based on access.
The story of the master protection model is as follows:
- Inputs (These are the directives to protect the data we store, process, and transmit)
- Mandatory directives communicate regulatory expectations
- Security standards and frameworks provide control specifications to meet regulatory expectations
- Compliance methodologies ensure ongoing control effectiveness
- Enablers (These are the business resources required to support our value proposition; together, they form your threat landscape)
- Hosting strategy based on a situational hybrid cloud model of access requiring protection
- Service and zoning modes of access requiring protection
- Technology supporting the services and solutions offered from our business portfolio that we must protect
- Output (This is how we protect our business enablers)
- Administrative controls in the form of strategic controls
- Catalogue of services required to provided enterprise protection
- Services transformed to functional areas of protection become the protection stack
- Technology solutions for enabling the protection stack
This is an information model rationalized from the contextualized components of the business mode from Part 1 of this blog series. Additionally, we embedded elements from NIST, The Open Group Architecture Framework (TOGAF),3 and the Information Technology Infrastructure Library (ITIL) to contextualize an enterprise view of the organization from three dimensions. Rationalization of the latter results in further contextualization of execution components; that is, those components from which outcomes are expected. Finally, a level of inheritance has been inserted in the domains where specifications may be inherited from common or baseline components to downstream components, (identified by red arrows in the preceding figure).
Sanity Check
If you’re an Information Security leader, how can you use this model with non-information security partners as a relationship-building tool to provide clarity of your strategy and discuss opportunities of collaboration?
If you’re part of the technical staff, based on the business model of your company, how would you conceptualize an Enterprise Security Protection Model? Can you identify the components of the model offering control inheritance?
In part 3, we’ll abstract from the master model to rationalize the threats of the Business Resource domain.
