Security Technology Executive

SEP-OCT 2018

Issue link: https://securitytechnologyexecutive.epubxp.com/i/1030460

Contents of this Issue

Navigation

Page 11 of 59

12 SECURIT Y TECHNOLOGY E XECUTIVE • September/October 2018 • www. SecurityInfoWatch.com CYBERTECH By Amir Sharif Amir Sharif has 20 years of experience building data center products integrating OS, v irt ualization, net working , storage, low-latency I/O, and orchestration. His executive experience includes running product management, engineering , and business development. A mir holds patents in RFID and distributed storage and received his MBA from UC Berkeley, where he was a Gloria A ppel Entrepreneurial Fellow, a Hitachi Mu Chip Fellow, and Mayfield Fellow. He started his career as a mathematician and soft ware engineer. doption of the cloud and cloud-native application architectures has become increasingly popular among develop- ers because it enables them to keep — even enhance — their competi- tive edge through innovation and ability to meet ever-changing business demands. These tools and methods provide substantial improvements for the DevOps team but for the security practitioner, they introduce concern and headaches regarding the overall security program. Often times, for DevOps teams, security mea- sures and procedures become a tradeoff for con- venience and capability. As DevOps professionals embrace the cloud, it breaks down the traditional security perimeter structure. This structure is the makeup of preexisting security practices and initia- tives lead by security professionals versus modern methods being implemented by DevOps teams which disaggregate the neatly packaged n-tier, VM- bound application into distributed architectures. From the Developer's Perspective: The developer is focused on access control and encryption requirements which are caused by security and data privacy mandates introduced by the security practitioner. While the developer is focused on building their business logic, they are faced with a few common challenges to meet these requirements. These common challenges include: • Encryption enablement: When enabling across all microservice components, there are changes required for applications while maintaining the associated public key infra- structure (PKI). As a result, any patches asso- ciated with encryption libraries will require re-deployment of these applications. • Distributed application programming interface (API) authorization: Authoriza- tion is key to ensuring all API requests within an Enterprise and any access to APIs from outside the Enterprise are sanctioned. By authorizing them in a distributed manner, it ensures this is properly done. • Increased overhead: For distributed applications, particularly those governed by strict compliance such as the payment card industry (PCI), secrets manage- ment and key distribution introduce overhead for the developer. From the Security Practitioner's Perspective: The security practitioner's primary goal is maintaining visibility, compliance, and control while embracing this architectural transformation towards microservices. In doing so, the security team runs into a few common chal- lenges that hinder them from achieving this goal. These common challenges include: • Application deployment velocity: The dynamic nature of microservices invalidates existing network security approaches. The common security practice of ticket-driven security requires a corporate secu- rity team to create new firewall rules that with each release greatly hampers the application deployment velocity. • Threat monitoring: Challenges are created for moni- toring the threat landscape at both the network and host layer when control is lost over the network and compute infrastructure. • Compliance: For both new application architectures driven by APIs and containers, it becomes increas- ingly difficult to assess compliance. As both the developer and security practitioner play vital roles in the successful enablement of a microservice, it is crucial to align on an effective security solution prior to implementation. For an organization looking for end- to-end security for their microservices and containers, there are three core tenants of an effective microservice security solution: 1. Comprehensive: Does the solution address the entire microservices stack? With a comprehensive microservice stack, there are three layers. These include the container runtime (the interactions of the container with the host), network access (the network traffic between microservices), and the API layers (the unit of consumption for microservices). When you only address a single layer, it will result in a myopic protection and detection solutions for two key reasons: How-To Secure Microservices and Containers With the rapidly growing need for security, teams need to understand the full set of requirements for a successful implementation A Continued on page 14

Articles in this issue

Links on this page

Archives of this issue

view archives of Security Technology Executive - SEP-OCT 2018