This is part 4 of the "Your Business Powered By Cisco Customer Solutions Architecture (CSA)" blog series.

Enabling & Delivering Cloud-based Security Services -Managed Threat Defense

Many enterprises (30%) have been leveraging cloud services cautiously or only in an internal (private) cloud manner. The reasons for this vary but these are the most common:

• IT applications (~80%) are not cloud enabled i.e. traditional client server apps or non-x86 apps
• Perceived security and performance concerns
• Perceived lack of control and loss of IT governance and policy

While these reasons are valid, the evolution of cloud services and the ability to transform traditional IT services, governance, and policy controls mean this Cisco CSA can now address these reasons.

This use case example focuses on Security because it is a major consideration for most customers.  The market growth for security is driven by increased demand for security applications such as network security and "confidentiality" of services.  Security services are seen as an emerging market and are expected to grow to$40B by 2017.  Managed Threat Defense is projected to be$3.7B of that$40B.

In today's environment, networks are getting much smarter and offer unprecedented abilities to see, monitor, and control traffic traversing the network. By leveraging these network capabilities, Cisco will provide a broad portfolio of cloud-based security solutions that deliver unmatched visibility and continuous advanced threat protection across the entire attack continuum, allowing customers to act smarter and more quickly -before, during, and after an attack.  There are many security use cases, and we have chosen Managed Threat Defense (MTD) for this paper. The figure, below, explains how Cisco will provision a CSA-based cloud to fulfill an MTD service for a customer.

1. The Services Catalogue contains only IT approved and security hardened images, middleware, and/or applications. The business user or developer requests the Managed Threat Defense (MTD) base service for their project from the list of approved catalogue items through the portal or API.
2. Basedon the catalogue item selected, the list of compliant and approved MTD cloud services will be available for selection. The fulfillment engine will gather all orchestration and internal configuration, monitoring, security, and identity components and send the configuration to the Cloud Automation engine.
3. The Cloud Automation engine will orchestrate the configuration and operations of configuring the MTD cloud service.
4. If required to instantiate the service, the Cloud Broker and Inter-cloud will manage the external cloud services layer and provision the requested services based on the business user or developer request. The CRUD capabilities of the Cloud Services are managed by this component.
5. Any external service components are enabled by sending API commands to the designated Cloud Service provider to provision those specific service components. The configuration and management of the Cloud Service is governed by the Service Management and Automation Layer.
6. The assessment of the security posture, and compliance to corporate IT policies, and monitoring of all events are performed via API gets. In addition, the usage billing metrics are collected via API and enhanced with ratings and chargeback capabilities.
7. The business owner is able to view the charges and usage for the project from the portal. The business user or developer is able to modify or delete the services or create additional services from the portal or API.

 Key Takeaways

Cisco's Customer Solutions Architecture (CSA) that details how various IT functions should be organized in a layered approach to achieve desired business outcomes. This CSA answers some key questions for enterprises and service providers such as:  What architecture maximizes virtualization, security and automation, how to realize architectural efficiency to deliver IT services, and how to evolve using the latest technologies and reduce on-going operating expenses (OpEx).

CSA is modular and consists of componentized sets of abstractions.

Customers may use this CSA as road map to transform their Current State Architectures (CSA) built with legacy technologies and systems into Future State Architectures (FSA) with the latest technologies and systems.  Due to the modular nature of CSA and CSA delivery, Customers do not have to transform all their CSA into FSA at once.  It can be done in a phased approach with mission critical areas in the early phases and non-critical areas in the later phases.  For example, private or public cloud may be deployed initially, and inter-cloud capability may be added later. Also, other technologies like IoT and Analytics may be added to the architecture in phases.

In the next blog, I will describe concrete CSA capabilities that a customer may use.

Tweet me @CiscoSP360 if you have any questions or comments.