Últimas notícias

Fique informado
#RSAC | 2016 Is the Year of Developer-Driven Security

#RSAC | 2016 Is the Year of Developer-Driven Security

26 de janeiro de 2016


Comitê Gestor da ICP-Brasil aprova emissão primária por videoconferência

A aprovação cria o amparo jurídico necessário para a edição da Instrução Normativa que regulamentará e viabilizará o processo operacional da emissão primária de Certificados Digitais através de videoconferência.

22 de janeiro de 2021

Veja o que diz Miguel Martins da AET Europe sobre gerenciamento de eIDS

Como traçar a estratégia de IAM para sua organização? Confira o que diz a AET Europe, líder global em gerenciamento de identidades.

19 de janeiro de 2021

Reconhecimento facial sem prova de vida está com os dias contados, afirma CEO de uma das principais plataformas brasileiras de biometria facial

Conversamos com José Luis Volpini, CEO da CredDefense, uma das pioneiras e mais conceituadas plataformas de biometria facial do mercado brasileiro.

6 de janeiro de 2021

Carimbo do Tempo dá início ao fim da era dos protocolos proprietários na ICP-Brasil. Ouça

Segundo Dr. Roberto Gallo, o fim da era dos protocolos proprietários na ICP-Brasil tem data marcada e deve beneficiar fabricantes, prestadores de serviços e clientes finais.

28 de dezembro de 2020

#RSA CONFERENCE 2016 | Tem início dia 29 de fevereiro em San Francisco

The 2016 digital Catalog Brochure – RSA CONFERENCE is here!

23 de janeiro de 2016
In the past 10 years or so, the security industry has gone through a number of paradigm changes, most of which were propelled by fundamental shifts in infrastructure or application-related technologies—think cloud or mobile.

By Chenxi Wang

One such shift that is rapidly changing the way companies are approaching security involves the increasing power of developers and how application infrastructure is being approached today.

Chenxi Wang Chief Strategy Officer, TwistLock

Chenxi Wang Chief Strategy Officer, TwistLock

In the past, everyone used to develop software for “boxed” products, where developers had no or little knowledge of what the runtime environment would be; this was true even for software developed in-house.

Similarly, security was largely developed to secure “boxed” applications. As such, the industry primarily focused on infrastructure-level protection like perimeter defenses, which treated the application very much like a black box.

There is a certain elegance to this model—except it didn’t work. Despite the tremendous amount of investment in network and infrastructure-level protection, many have failed to protect customer data and critical information.

When “cloud” came along, developing for “SaaS” was a different experience that required very different software design and security practices.

For starters, it was no longer sufficient to have a few major releases per year for cloud applications. Daily, or sometimes even more frequent updates were required. This, in turn, required a more agile software lifecycle management approach, which ultimately led to the methodology of Continuous Delivery and Continuous Integration (see Figure 1).

software development

Figure 1: Software development practice change

To achieve continuous delivery, you simply can’t have monolithic applications because no one can afford a complete overhaul of the application for each update. As a result, application architecture gradually migrated toward a collection of inter-linked software components, known as micro-services (see Figure 2). Each micro-service can be updated or replaced independently of others, which not only enabled Continuous Delivery, but also help to promote portability and standards-based development.

application development

Figure 2: Software architecture change

This fundamentally changed the economy of scale for software development, the speed of delivery and ultimately, the pace of innovation.

This creates a new environment that requires fundamental shifts in the way we approach today.

First, you now have tons of new bits being dropped continuously into production, without IT Security or Ops being able to review them a priori—what typically happened with “boxed” software. This means you either become a naysayer, or relent to giving developers carte blanche for deploying anything they want to production.

Neither sounds like a very attractive choice.

On top of that, you begin to realize that your relied-upon infrastructure-level security is failing, because the controls lack the visibility and granularity that you need to effect continuous integration-style deployments.

To get around this, Security and Operations need to adopt a developer-driven mentality.

What is developer-driven? When boxed software becomes API rich, it signifies a developer-friendly environment. Being developer-driven takes it to the next level; an environment qualifies as developer-driven when developers get to determine (or play an active role in determining) runtime dependencies and stipulate operational policies. A concrete example of a developer-driven environment is container-based infrastructure, where developers construct container images and encode runtime dependencies within the image and push them directly, possibly continuously, into production environments.

To enable and function in such an environment, security needs to become developer-driven. A developer-driven security model has these characteristics:

a) The fundamental properties of the model are stipulated in development time,

b) The implementation comes together automatically and dynamically in runtime, and

c) It provides a verifiable level of security

Before that becomes a reality, a few things need to happen.

  • Stardardization of security abstractions: Certain security functions need to be abstracted into plug-and-play yet programmable components to support a developer-driven model. Very much like how NFV abstracts networking functions, we should see security functions like firewall filtering, low-level intrusion detection, authentication, etc., become abstractions. That way, developers can specify “what” to do in terms of security, rather than “how” to do it in runtime.
  • Augmentation of the DevOps process: The current DevOps process and the orchestration layer that launch software packages into production are essentially a black box to Ops and Security. Tools are needed to augment these processes to allow lightweight inspection and verification that the processes do follow standard policies.
  • Real-time visibility and feedback loop: As security becomes developer driven, it’s especially important for the system to have real-time visibility and a feedback loop for dynamic controls. Just as application functions are being continuously deployed into the production environment, security will become a constantly-adjusting lever as new functions are being introduced into the system and new threats arise on the horizon.

If 2008 was the year of mobile security, and 2010 was the year of cloud security going mainstream, 2016 will be the year of developer-driven security, regardless the location of your infrastructure and the types of devices deployed.

* Chenxi Wang  | Chief Strategy Officer, TwistLock

rsa 3

Fonte: http://www.rsaconference.com

Nenhum comentário até agora

Ir para a discussão

Nenhum comentário ainda!

Você pose ser o primeiro a iniciar a discussão.