Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

2/15/2018
02:30 PM
PJ Kirner
PJ Kirner
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Democracy & DevOps: What Is the Proper Role for Security?

Security experts need a front-row seat in the application development process but not at the expense of the business.

With the advent of the cloud and DevOps, the job of implementing security has been dispersed more widely across IT. This has led to significant gains in speed and agility, but it has also created unacceptable risk for the business. For security, the pendulum has swung too far toward democracy. We need to pull it back.

It's easy to forget that as recently as a decade ago, IT in a pre-virtualization/pre-cloud world looked very different from today. Software projects were measured in months if not years, and security teams had control and visibility over all that went out the door. This ensured less risk, but as dev teams tried to move faster, security quickly became the infamous "department of no." If CSOs weren't banning projects outright, they were certainly holding them up to ensure every possible door to a vulnerability was closed.

DevOps is a great frontier by comparison. These days, software and infrastructure teams are implementing new features and services at a remarkable place, aided by higher-level tools and a myriad of third-party services in the cloud. Just this past year alone, swift advances in areas like containers and serverless computing have allowed dev teams to do far more with less.

It would be unfair to say developers aren’t attuned to the needs of security — the constant drumbeat of major breaches means that everyone is now aware of the need to lock down applications and data. And the major cloud providers have invested heavily to secure their infrastructure and provide built-in tools and protocols for securing data and connections.

But this is precisely the challenge. As DevOps turns to these off-the-shelf mechanisms to secure applications, they fall prey to an illusion of security. That's not a criticism of cloud providers; it merely reflects the reality that security in the enterprise is highly complex. Organizations develop security policies for a reason. Not all data is equal, and highly sensitive information, such as customer or financial data, must be afforded higher levels of protection. 

Networks and systems are also complex, and potential attack vectors aren't always apparent when applications are built quickly and modified frequently over time. Security experts need a front-row seat in the DevOps process, because they are the individuals uniquely trained to identify these vulnerabilities. But in the democratic model of security, their role is too often reduced.

Clearly, we do not want to roll back the advances of recent years and inhibit the ability of dev teams to innovate quickly. But developers, ops, and security teams must each acknowledge their respective areas of expertise and work together to ensure that the risks inherent to moving quickly without sufficient care are mitigated.

Security must not be a bottleneck, but the democratization of security through DevOps has been an overcorrection to the time when security had absolute control. If the right model for security is not a pure democracy, where everyone has an equal say in policy and no one is ultimately responsible, then we should think of it more as a representative democracy — where power resides in the people, but that power is exercised through elected representatives.

What does this imply for application development, IT operations, and security governance? That the elected security representative — the CSO — is accountable to the organization and therefore carries out its will (no more "department of no"). But the CSO also has authority to decide how that will should be implemented, because ultimately, it's the CSO who is accountable for keeping the business secure. 

Getting to the model of a representative democracy requires a change in how security, dev, and ops teams work together today. Here are three best practices to help make this happen.

  • Each team must recognize the knowledge the other teams bring to the table. While there needs to be a baseline understanding, no single constituent can be specialized in all aspects of application development, deployment, and security. Without respecting each other's expertise, there's no way to move fast and be secure at the same time.
  • Consider new training to ensure teams know the limits of their knowledge and the needs of the other teams. For security professionals, this means keeping up to date with the latest development methodologies and services in the cloud. For developers, it means learning the limits of their security knowledge, and knowing when to ask a specialist for help.
  • Teams need to meet regularly to review their shared understanding and raise needs for specialists on the projects they are working on. Cooperation happens only through proactive dialogue. Put a monthly meeting on the books today.

Automation, virtualization and the cloud have brought sweeping changes to how applications are developed and delivered. IT is a far more exciting and dynamic place to be than it was just a decade ago, and technologists have far more impact on the success or failure of business. But that also brings new levels of responsibility. A single security incident can affect the valuation of an entire company. Dev teams and security staff must work together to ensure this does not happen.

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

As chief technology officer and founder, PJ is responsible for Illumio's technology vision and platform architecture. PJ has 20 years of experience in engineering, with a focus on addressing the complexities of data centers. Prior to Illumio, PJ was CTO at Cymtec. He also ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
Architectural Analysis IDs 78 Specific Risks in Machine-Learning Systems
Jai Vijayan, Contributing Writer,  2/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2228
PUBLISHED: 2020-02-19
The XStream extension in HP Fortify SCA before 2.2 RC3 allows remote attackers to execute arbitrary code via unsafe deserialization of XML messages.
CVE-2014-2727
PUBLISHED: 2020-02-19
The STARTTLS implementation in MailMarshal before 7.2 allows plaintext command injection.
CVE-2015-2104
PUBLISHED: 2020-02-19
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2014-3622
PUBLISHED: 2020-02-19
Use-after-free vulnerability in the add_post_var function in the Posthandler component in PHP 5.6.x before 5.6.1 might allow remote attackers to execute arbitrary code by leveraging a third-party filter extension that accesses a certain ksep value.
CVE-2016-10000
PUBLISHED: 2020-02-19
Insufficient type checks were employed prior to casting input data in SimpleXMLElement_exportNode and simplexml_import_dom. This issue affects HHVM versions prior to 3.9.5, all versions between 3.10.0 and 3.12.3 (inclusive), and all versions between 3.13.0 and 3.14.1 (inclusive).