Application development is in a period of transition; it seems everyone is moving to faster-cycle development paradigms like DevOps and Agile while new release and deployment paradigms like application containers (Docker), platform as a service (PaaS) and microservices simultaneously gain traction. That change is happening everywhere, but in a retail context, there are special considerations that make these transitions more complicated.
Specifically, PCI (both the DSS and the application-specific PA-DSS) are front of mind in a retail situation. An in-house developed application could potentially be fielded into the cardholder data environment (CDE), bringing with it specific security requirements (including application-specific requirements) that must be addressed. One of the complicating factors is that these requirements need to be a consideration even where the application isn’t intended to support payment processing directly. Why? Because the scope of the DSS extends to areas that are not segmented from those that store/process/transmit cardholder data. This means that the manner in which the application is deployed (including, for example, underlying network segmentation) impacts whether or not PCI is in scope. Moreover, post-deployment changes, such as which hypervisor the app runs on, segmentation in use, etc., can put an application into or out of scope regardless of what the developer intended.
As a practical matter, then, security is an extremely important consideration in the development of retail applications. Moreover, the regulatory context is such that we need to account for it regardless of how developers – or even the security team – might perceive the application usage at the outset.
Security Challenges -- and Opportunities
With this in mind, it is important for organizations in the retail space – or in fact for any merchant, service provider, or organization in the payment community’s supply chain – to systematically address application security hygiene as part of the development process, particularly as they embrace new development methodologies like DevOps. While this is an area that many security teams have historically struggled with, there are a few strategies that can be used to help make this easier; in fact, the move to DevOps can provide ammunition to security teams to help them gain additional value in their application security efforts. We’ve outlined a few of these below.
Note that this is not intended to be an exhaustive list; there are of course dozens (if not hundreds) of possible strategies and approaches that an organization can have in its toolbox. However, these approaches have the advantage of being relatively easy to implement, leverage existing tools and methods, and provide additive value to the security organization.
Strategy 1: Automation of Application Security Controls
One of the ways in which DevOps often accelerates the release of software is to automate certain aspects of deployment – for example the push of code to production, certain aspects of QA, and/or configuration management tasks. One of the areas that can be likewise automated is the scanning of software changes for “low-hanging fruit” application security issues like SQL injection, cross-site scripting, or other easy-to-locate issues. Incorporating application security checks and balances into an automated release cycle can be very helpful as it provides a security-relevant check into the deployment process. This can occur naturally and seamlessly as part of the release process just as other QA elements do. The results of the testing can be either reviewed manually, shared with development teams, or (depending on the level of sophistication of the organization and specific usage) act as a check where a vulnerability above a certain severity could cause a code push to require further review before being injected into the production environment.
Strategy 2: Leverage Automated Configuration Management
Another useful approach is leveraging configuration management tools, such as those that might already be in use to support DevOps or that are planned as part of a switch to a DevOps approach to support security activities and goals. Configuration-related security hygiene activities such as patch management, maintenance of a hardened configuration, or managing application inventory are natural fits. Leveraging the same tools that support automation of configuration changes to provide reporting and analysis on the security status of production configurations has advantages. Specifically, data gathered in this way is likely to be as current, reliable, and timely as possible.
Strategy 3: Threat and Situational Awareness
The last strategy we’ll discuss involves expansion of (and integration into) intelligence-related security techniques into application security efforts. Threat modeling has a long history as a productive technique to ensure that applications are designed in a manner that maximizes security protection; recent developments in intelligence-driven security methods can provide additive value when threat modeling efforts are aligned. For example, kill chain analysis techniques that seek to disrupt an adversary’s campaign are often planned and developed without full cognizance into what’s happening at the application layer. Integration of application-layer threat analysis (e.g. systematic threat modeling) techniques therefore can operate synergistically with these efforts as application context is added to situation awareness building and can influence countermeasure deployment.
In summary, the move to DevOps is often seen as a “security negative” – i.e., a situation where security efforts become harder to accomplish and application deployment becomes riskier. However, despite this perception, there can be – and often are – positive security outcomes to be had. Specifically, expanding on and integrating existing efforts into the broader application security approach can happen in a few ways. Keeping an eye open for these opportunities can yield a few welcome surprises and help the overall security posture improve synergistically.