72 days after the fact AdultFriendFinder.com, a “very mature” dating site, realized they had been hacked. The VERY personal information of 3 million registrants has been held hostage. By now, it should be clear that in the modern software development world, old-style static security just won’t work. Of course, there are times when the static security model still applies — for example, on a relatively stable, hardware-based system with traditional, non-continuous deployment and a limited traffic volume. Such environments can easily be routed through a checkpoint with no significant loss in performance.
But these days, such a system qualifies as a trivial case; in a DevOps environment, none of those conditions apply. In DevOps, rapid change is built into the process, virtualization and shifting platforms are common, continuous deployment is the rule, and traffic volume tends to be very high, often with few clearly definable checkpoints.
While it is clear that DevOps requires a DevOps security model, all too often, the overall relationship between DevOps and security is still an uneasy match. The basic problem is that even though the old model of static security won’t work, the new security model is still being defined. It can’t simply be a compromise between the demands of DevOps and those of traditional security systems; it must be a model of security which by its basic nature is integrated with the philosophy and practice of DevOps.
While it may not be possible at this point to describe what a fully-realized implementation of the DevOps security model would look like in detail, we should at least be able to see its broad outlines, and to identify some of the key requirements.
Security in the DevOps world needs to be able to operate without imposing checkpoints, chokepoints, or bottlenecks.The high volume of data in many situations simply won’t allow it, and even more than that, the fluid nature of contemporary deployment makes it impossible for all practical purposes. Security software originally designed to monitor all traffic at the hardware level has very little relevance in a world of rapidly-shifting virtual system. Monitoring needs to be on the level of application behavior and system behavior, combined with the ability to quickly trace anomalous behavior to the source.
For this reason and many others, DevOps security must be adaptive security. What does that mean? Among other things, it needs to be able to adapt to the environment and to the demands being placed on the software. Is a packet of data going to be used within the system, or is it crossing the system boundary? Where is the system boundary at the moment? Is the system running on physically discrete hardware, or is it in a virtual environment with added layers of security?
Adaptive security also needs to have intelligent, flexible strategies for dealing with a very high volume of security data. It can’t afford to simply log data, or alert a human operator. It needs to be able to make decisions and respond within seconds (or milliseconds) after detecting anomalous behavior. But even the act of detecting an anomaly requires a way of understanding what is and what isn’t anomalous behavior — an understanding which is in turn dependent on the adaptability of the security system.
A static security system operating in an environment with a relatively limited set of ways to interact with the outside world may be able to define anomalous behavior by means of a blacklist — a (presumably exhaustive) list of actions initiated from outside which may be malicious. In a dynamic, continually shifting environment, the blacklist approach won’t be adequate, because tomorrow’s malicious intrusion may require conditions which don’t exist today. Blacklist-based security is likely to be chronically one or two steps behind cutting-edge intruders.
The most promising alternative is whitelist-based security ( otherwise called policies), which uses a comprehensive list of non-anomalous system behaviors, and flags any behavior not on that list. Notice that we said “system behaviors,” and not “user behaviors”. In an unstable external environment, it is easier to predict how the system should behave internally than it is to create an exhaustive list of acceptable interactions with the outside world. We may not know what a malicious user request will look like next week, but we should be able to get some kind of picture of how the system will respond internally to a valid user request. And once we know that, we can flag any response that doesn’t look right for a valid request.
But such a whitelist can’t be static, either, because acceptable system behavior will change, and in a DevOps environment, it is likely to change rapidly at times. The security system needs to continually update its list of non-anomalous types of system behavior. Keeping a whitelist up to date is also easier than it would be with a blacklist, since the development team will typically be able to describe the expected behavior associated with new or changed features.
Security in a fluid, high-volume environment needs to be able to adaptively prioritize its response to incidents. Changes in system or user behavior caused by changes in the application may still require the notification of security personnel in order to verify the new behavior as acceptable. Because such verification will affect future system responses, it should have relatively high priority — requests should not be lost in the flow of ordinary security alerts. After the new behavior has been verified as OK, future instances of that behavior can have a much lower priority.
This kind of whitelist-based system requires the security team to be integrated into the DevOps process to the point where it will be routinely told when new features, interfaces, platforms, etc. are being deployed, and what behavior to expect from them. The days when security can be an add-on, an afterthought, or a responsibility that’s left to “somebody else” are gone.
Security integration (and not just the inclusion of individual security features) should be a major consideration in software design, and in all of the phases of the DevOps cycle. All of the silos must come down: Adaptive Security must be as much a part of DevOps as are Development and Operations themselves.
Photo credit StockUnlimited.com
