devopsy.kinsta.cloud

Tag: devops security

Simplify DevSecOps with a Zero Trust Approach

There are major cyberattacks and data breaches weekly, if not daily. Each incident is unique in some way, but one element common to almost all successful attacks is trust. Whether it’s a disgruntled employee conducting an insider attack, an attacker infiltrating the network using stolen credentials or an exploit that leverages a third-party vendor or supplier, what makes the attack possible and allows attackers to fly under the radar is the fact that the credentials and activity appear to be legitimate. A zero trust security approach could solve that.

In DevOps environments, where new application architectures such as microservices and containers make things much more dynamic and rapidly changing, security can be especially difficult. Automation, virtualization and new tools combine to increase the potential attack surface exponentially. And, granting and removing access for containers or virtual machines that appear and disappear by the hundreds can be a Herculean task—traditional permissions management and access control solutions just can’t keep up.

“DevOps creates a challenge for many organizations because they need to maintain agility while also recognizing that security is an increasing concern in broadly distributed networks,” said Bill Mann, chief product officer at Centrify. “Prioritizing functional requirements over security while building applications leaves organizations exposed to significant risk.”

Centrify, however, is up for the challenge of bringing zero trust security to DevOps environments. The company claims to simplify integration of security into DevOps applications development pipelines without restricting development velocity.

Centrify starts with the premise that users, applications and endpoints are not trustworthy by default. Everything must be verified at every point of access to ensure that security of the development pipeline is not compromised in any way.

Its DevOps-focused portfolio includes products that help developer, security and operations teams manage access to complex development environments, enhance application security and provide auditable logs of privileged activity. Centrify provides centralized management of user access rights and privileges to Linux and Docker hosts, including hosts running CoreOS Container Linux. I am especially intrigued by its ability to implement multi-factor authentication (MFA) and temporary privilege elevation to gain access to individual containers independent of the container hosts.

Centrify also announced that it can now be used to authenticate to HashiCorp Vault, one of the most popular tools for securely strong and accessing secrets. Centrify provides centralized access management for the Vault, as well as protects against malware attacks by eliminating the need for locally stored access credentials.

On the application security side, Centrify focuses on securing privileged service and system accounts and enabling secure communication between applications, containers and microservices. Centrify leverages Kerberos, SAML or OAuth to enable services authenticate to each other.

The basic premise of Centrify is that “trust but verify” sounds good in theory, but in reality “never trust, always verify” is a much better strategy for security. Rather than hoping you can find the needle in the haystack and identify the one bad actor, it makes more sense to assume the bad guys already exist both inside and outside your network and simply remove trust from the equation.

The approach certainly seems to have some merit. It’s sort of like applying a whitelist instead of a blacklist to filter email or applications. Rather than assuming everything is good and trying to find the bad ones, just assume everything is bad and only let through the ones you choose. In this case, however, you don’t even have the whitelist. You’re literally verifying the user and device and applying policy to determine the level of access and privilege each time.

— Tony Bradley

April 19, 2018
appOrbit: End-to-End Hypercloud

As cloud and DevOps have heated up, enterprise need for cloud portability and deeper DevOps integration have become pretty clear. The need for portability to avoid cloud lock-in has been a desire of enterprise cloud users from day one. A variety of people are attempting to address this need, but the market is still very much evolving.

In the area of DevOps integration, the two topics currently causing struggles are security and networking. Continuous deployment inevitably requires both to be part of the DevOps package, and those are the newest additions to the field, so it is still maturing.

Enter appOrbit

appOrbit recently came out of stealth mode with an overarching architecture to enable hypercloud and extend the DevOps process across the entirety of the dev/test/deploy ecosystem. The idea is to offer a platform that doesn’t care what languages or deployment tools you use, or even what databases you’ve tossed data into, and covers the process from first line of code to management and monitoring post-deployment.

That’s a big claim, so I got on the phone with appOrbit to poke around a bit. Better would be to take the time and use the toolset, but I’ll settle for our questions about the traditional weak spaces in the process, and about how they achieve some of the company’s claims. For now.

My first impression was that this was application release automation/application release management (ARA/ARM), and Rahul Ravulur, CEO of appOrbit told me I wasn’t far off; I just wasn’t thinking big enough. A large part of the process is ARA, but additionally, appOrbit worries about networking, security policy and long-term monitoring and management, all while offering deployment portability.

Finally, the End Game is in Sight

From the beginnings of the Ops side of the DevOps movement (what I like to call devOPS), the end goal was pretty obvious: to improve the entirety of the process. It was clearly going to take time—good network engineers are wizards that can make a network do astounding things—and we had to figure out how to make that more repeatable. On the DEVops side, repeatable was relatively painless: We already did a predefined sequence of steps over and over; the point was to break them into smaller iterations and automate what was ripe for automation. Much of Ops was the same, but networking and security had many more variables to take into account, and less history of “here’s a prescribed sequence, do it.”

If appOrbit can do as it claims—and its customer list includes some customers I’ve worked with that probably wouldn’t be there if the product was vaporware—then we’re seeing the culmination start. The culmination will include limitless portability, sort of a “we don’t care where you deploy, just tell us and we’ll do it”; it will include development tool agnosticism—“We don’t care what tools you used, we’ll deploy it”; and it will include complete solutions—“We’ll move your data, we’ll move your app, we’ll configure the target network, we’ll run the security checks relevant to the target platform.” It sounds like appOrbit has traveled quite far down that path already.

What, Exactly, Did You Intend?

One interesting bit appOrbit talked to me about and I’d like to take out for a spin is the idea of adding “intents” to security and networking. Tell it what you’re after, and through a combination of built-in functionality and plug-ins it will deploy your application as you intended. For things like opening a port, this seems pretty straightforward, but security and networking are complex topics. What is/isn’t covered by security policies/intents? What if my intent is for the system to create a VPN, lock down all the ports, then open just a few and connect the VPN back into the data center over an encrypted port? Who manages certs? Where does it get the credentials to get back into the data center? What happens if I take this whole VPN-based deployment and decide to put it inside the data center after all? Do I have to rework the networking intents to remove the VPN? The questions are endless.

But assume this is the beginning of a road that truly can end up with “deploy anywhere, and deploy as you intended.” That’s what we’ve been waiting for, and it’s inevitable, so I for one am glad to see us set off meaningfully down the path.

Improvement Makes Movement

The mere act of someone talking about having pulled all this together will be good for customers. Ravulur’s stress that “a lot of what we do is ARA” will no doubt make ARA vendors step up their attempts to be as inclusive as appOrbit is, and the market will move forward. appOrbit’s use case of “legacy app migration” without changing the app alone offers an avenue for enterprises to begin to move to new platforms. That in and of itself will be a help to the huge number of enterprises that want to move to a more modern environment but aren’t ready or able to rewrite entire systems. And again, it will spur on competitors—in this case in the application provisioning space, most likely—to try and implement similar functionality in a relatively short time frame.

Beyond Hope

In a nutshell, I hope that appOrbit can do all that it claims, but even if it falls short in some areas (I honestly have only touched on a few of the areas it has pulled together; there’s a lot here), it is a step forward, and I think the company will drive the market more toward the end goal of application portability from both the Dev and deployment sides, while automating a more complete solution.

To me, that’s all good. Not everyone is pure cloud, and a far fewer number want to be pure public cloud brand X. The automation tools I’ve been knee-deep in all have been massively complex under the covers, and no doubt this one is, too; simplifying automation so it is easy to adapt to a given environment is a huge part of the task these tools perform. Figuring out the weaknesses is what we customers have to do, but in the end, we’re moving forward.

I, for one, will look for a chance to play with appOrbit’s toys, validate some of its claims, and see how well it suits enterprise needs. But I don’t have a timeline, so if you’re interested, you should check them out yourself.

— Don Macvittie

July 14, 2017
Mesos: Security Awareness and Considerations
As regular readers know, I’ve been digging into Mesos quite a bit these days and, for the most part, enjoying the entire ecosystem that has grown up around it. There are some very cool possibilities when organizing servers into one massive platform for application (or micro-service) delivery. While there is a bit of a learning curve, I wouldn’t say it is as bad as the application provisioning tools out there, and there is the ability to scale and manage apps while maintaining but a single reference architecture.

But every technology has its issues that we need to be honest and open about if they are to be successful in the enterprise. Mesos is no exception.

Most open-source projects start out with, “If we just did X, Y and Z, we could do this cool thing!” and only afterward consider the security needs of the target audience. This is kind of the nature of the beast, and Mesos is no exception. The Mesos team is currently on the path to enterprise-grade security from little (or optional) security, but for right now, here are things to consider to help make your Mesos installation secure.

According to Ben Hindman, Mesosphere co-founder and co-creator of Apache Mesos: “For folks that were running without authentication, we didn’t want to break their clusters when they upgraded. Authentication will be on by default after sufficient time for frameworks to get upgraded. We enable a mixed mode where some frameworks can authenticate and others don’t exactly to support this upgrade path.”

The thing is, the default upon installation of Mesos at this time is to have no—I repeat no—authentication for frameworks, and no limitation on what those frameworks can see. If you use command line switches, you can modify this default behavior, but the default is still to be wide open where frameworks are involved. The point of this blog is to urge you to use those command line switches if at all possible in your environment.

It is industry standard to do the exact opposite of what Mesos does—to offer an option to turn off security—but to have it turned on by default. And while it makes initial pilot deployments more difficult, that is precisely what Mesos needs (and, judging from Ben’s comment above, plans) to do.

The following items, taken together, create the core problem:
1. By default, Mesos allows frameworks to register without authentication (see link labeled “command line switches” ,above). Normally, some form of authentication is required. Increasingly, OAuth access control is being utilized. See Stormpath or DigitalOcean for examples of API Authentication design.
2. Mesos uses “roles” to determine which frameworks have access to what resources. By default, a framework can register for any role.
3. Persistent disks (such as your database or your contracts directory) can be resources assigned in Mesos. Access is controlled by role only (last bullet point before version history), to make them available to multiple apps on multiple frameworks. This also makes access available to any framework that assumes the same role as those with access.
4. Mesos can distribute agents to each node in the cluster as needed via the mesos fetcher. So distribution of agents, which would be a limiting factor to this weakness, is actually easy—a framework can request that its agents be downloaded to any server in the cluster, on demand.
5. There is a public framework development guide.
So with a default Mesos installation, and any machine that can hit the REST API for frameworks, I can register a framework of my own construction. The Mesos system has automated approval of registration, so there is no human decision-making involved; registration (called scheduler subscription) implies approval if authorization is not enabled, and the response includes registration information. Considering that the frequency of adding frameworks should be minimal, this is a good place to have a human involved in the process. Note that older framework development using libmesos.so could also abuse this default, but that route is harder, and thus less likely to be utilized. My new framework can supply roles that exist in other frameworks, and I can then gain access to these static resources simply by waiting for Mesos to hand me the correct resources. These resources could include any persistent disk assigned to that role, with read/write access (because the current incarnation of Mesos only supports read/write). This came to my attention while working on Mesos with Marathon, but is possible simply with Mesos.

Again, this is a known issue and the Mesos team is slowly moving toward resolution. But for now, users need to lock down their own implementation if their environment will allow it.

The workaround is easy enough, there are command line options to turn on authentication for frameworks, and to limit which frameworks can use what roles. But you have to turn both on—they are off by default—and looking through the logs on my Mesos cluster, it does not appear that framework registration is logged with default logging settings. Note that role management has overhead, but when applied to frameworks is not a large security burden unless operations is constantly adding/removing frameworks from the system (which is highly unlikely). Also remember that the reason the system is currently designed to work both ways is that some frameworks do not yet support authentication, so testing with this feature turned on is a must before rolling it out in production.

Do I rate the risk from this issue to be huge? Honestly, it depends upon your implementation. If the Mesos cluster in question is putting sensitive information on a persistent disk, the risk is potentially high. If the cluster in question is not, there is still risk from the architecture design and lack of authentication, but the data available—and how it is protected outside of Mesos—determines how hazardous an attack would be. The ability to modify the configurations of running applications is a further concern; HTTP redirections alone could be troublesome.

In short, the existence of this transition period is going to make me more aware of the security implications of everything else in Mesos, simply because it shows a failure to follow common practices and might indicate that other places in the project suffer similar security design decisions, though the move toward fixing authentication will make me less hypercritical.

Note that I wanted to get this info out there, thus have not yet taken the time to explore exploiting this issue on my cluster. Implementation almost always provides different information/issues than researching offers, as it is a different stage of the process. I will update when I have time to make a pair of frameworks, one “normal” and one “attacker,” to test with. In security, it is always best to test out issues first, but these are well-enough documented, I opted for notifying the community before embarking on a potentially lengthy proof.

It is not the point of this post to imply that Mesos should be avoided. The point is to advise you that the “Command Line Switches” link (above) should be followed, read and the guidelines for turning on authentication should, at a minimum, be implemented. I would recommend limiting roles also, but at a minimum, turn on authentication for frameworks and test if it works in your environment.

I’d like to thank Ben Tomhave, Security Architect at New Context, for helping me out on some of these points. If there is any error in my analysis, it is mine alone, but the blog is far better for his assistance.

— Don Macvittie
December 8, 2016
HashiCorp Vault Enterprise Secures DevOps Infrastructure
HashiCorp, a DevOps infrastructure company known for its Atlas platform that combines a variety of powerful open-source tools, recently announced Vault Enterprise. HashiCorp describes Vault Enterprise as a comprehensive security solution for DevOps infrastructure. Vault Enterprise is the foundation for security in the HashiCorp DevOps infrastructure suite.

Open source is a virtual necessity for effective DevOps—forming a close symbiotic relationship. I explained in the DevOps and Open Source report published earlier this year, “There are some significant advantages with FOSS (free and open-source software). With a proprietary, closed-source application there are very few people with access to look at the code. Recent incidents with SSH backdoors demonstrate that closed most certainly does not mean secure. When the code is open those types of backdoors can be quickly spotted and resolved.”

With the addition of Vault Enterprise, the HashiCorp suite is now comprised of:
- Vault Enterprise – Empowers security teams to collaborate, validate, and enforce security policies
- Terraform Enterprise – Empowers operations teams to collaborate, validate, and provision infrastructure
- Nomad Enterprise – Empowers development teams to collaborate, validation, and deploy applications
- Consul Enterprise – Empowers all teams to monitor the complete stack
Vault Enterprise is not entirely new. It builds on the open-source Vault to enable security teams to define and enforce security policy and secrets management across distributed infrastructure.

“The shift to highly elastic, microservice architectures requires a different approach to security. Static network-based security is poorly equipped to handle the dynamic application-centric infrastructures being built today,” said Armon Dadgar, co-founder and CTO of HashiCorp. “Vault Enterprise enables organizations to adopt DevOps practices in their approach to security and keep pace with development and operations teams that are adopting DevOps.”

Vault Enterprise includes Hardware Security Module (HSM) integration, which enables developers to integrate Vault Enterprise with HSMs using Vault’s simple API rather than more complex HSM interfaces. According to HashiCorp, there are also a variety of enhancements and new collaborative features in Vault Enterprise, including a new UI for managing secrets, health alerts and monitoring and an intuitive workflow for initializing new Vault clusters.

“Deploying enterprise software to both public and private cloud infrastructure requires a security solution that works everywhere. As we adopt DevOps practices that make our applications and infrastructure more dynamic, we need bullet-proof security,” said John Mitchell, Architect at SAP Ariba. “HashiCorp’s Vault is the only offering that meets these requirements—one workflow across providers and dynamic secrets management.”

DevOps is a culture and a process—not a silver bullet solution or a single product. HashiCorp understands this while still trying to provide a DevOps infrastructure platform that’s as complete as possible. HashiCorp pulls a variety of effective and useful leading tools together, and delivers them in a modular fashion that allows you to embrace DevOps at your own pace.

There are plenty of vendors out there creating proprietary tools and platforms. What I like about HashiCorp is how it is harnessing the power of an array of open source tools to provide a whole greater than the sum of its parts. Vault Enterprise is available now.
September 9, 2016
The DevOps Force Multiplier: Competitive Advantage + Security

Several years ago, DevOps started hitting the eyes of enterprise business leaders when news outlets such as The Wall Street Journal and Forbes began reporting that the IT culture and methodology was helping adopters to gain a competitive advantage. Since then, we’ve seen story after story about how DevOps-focused employees are becoming the driving force behind the software and applications the world relies on for everything from mobile banking transactions to ride-hailing to gaming. Even the Pokemon company can’t get enough DevOps engineers.

It looks as if DevOps soon may be recognized as more than just a force for fast and agile software development and deployment. Evidence is emerging that it also may be having a positive impact on security.

Security Researcher Sees Trend

Bugcrowd Security Researcher OJ Reeves

Bugcrowd Researcher OJ Reeves sees his fair share of weak security. As a full-time white-hat penetration tester and researcher running attack simulations for enterprises that want to improve their defenses, he’s seen everything from unpatched vulnerabilities in software to the perilous journeys overshared credentials take as they’re passed between multiple administrators across various communications channels.

Recently, Reeves noticed that in our facepalm-ridden world of security blunders, organizations with a DevOps focus seem to have better security.

“DevOps is young and still being defined differently across organizations,” said Reeves. “I have noticed recently that when I engage with businesses that employ DevOps-focused people, a security mindset often accompanies.”

The reasons behind why DevOps is assisting with creating more secure environments are wide and varied, Reeves cited several.

DevOps Checks Boxes — All of Them

“Check box security” can be a bit of a dirty-word term when it comes to protecting systems and data, as it frequently refers to compliance—something many cybersecurity and risk professionals consider to be the bare minimum when it comes to protecting data and systems. At the intersection of DevOps and security, it actually can mean something very different, Reeves said.

“Organizations that actually have DevOps people in place tend to do a better job checking all boxes and making sure security is in place,” he said. “When you have a DevOps person who is doing the job properly, they (organizations) have a much better chance of defending themselves.”

DevOps Makes Fewer Mistakes

One company Reeves attacked had developers, operations and infrastructure employees in place but no DevOps-focused team members. He noticed right away that there was no clear definition of who was responsible for security or who was in charge of protecting application life cycles.

“There were credentials everywhere—all spread out and all mismanaged in different ways,” he noted. “You don’t want anyone with malicious intent, who can compromise a developer’s’ desktop, to get access to credentials.”

When running simulations for organizations with DevOps employees in place, he’s observed that those kinds of mistakes happen less frequently.

“More often than not I’ve found that the credential management process is much better when DevOps people were present. When there is a person in charge, who is also conscious of how others are using credentials, a credential security champion tends to emerge,” he said.

DevOps Communicates

Reeves, like many other practitioners I’ve spoken with, emphasized that communication between IT members is critical to effective defense. That’s something he said DevOps-focused organizations seem to be especially good at doing.

When privy to conversations taking place between developer, security and DevOps employees, Reeves has noticed that everyone involved is interested in improving processes all around—processes which include security.

“Direct human interaction that takes place between those who are responsible for defense tends to result in improved security,” he added. “Just the fact that awareness for these [security] issues is being raised and discussions are taking place is having a positive impact.”

Reeves indicated the discussions taking place within DevOps environments he’s observed are focused on the right things.

“These human-to-human interactions make things more secure and they pay attention to organizational security, where we should be having our discussions,” he noted. “Let’s not talk about the latest AV (anti-virus), etc.; security is an organizational process and problem. The best security in the world doesn’t matter if employees in the organization aren’t aware of what’s taking place.”

DevOps: Harder to Crack

At the end of the day, companies such as Bugcrowd and pen testers such as Reeves are paid to find exploitable gaps in systems so they can be closed before the nefarious can take advantage of them. While DevOps isn’t typically thought of as a security enabler, organizations that don’t have dedicated DevOps employees may want to consider Reeves’ parting words: “When organizations I am researching have a DevOps focus, it is generally more difficult for me to compromise them.”

July 28, 2016
Zero Trust Is a Key to DevOps Security

Once upon a time, network and endpoint security was a simple matter of us vs. them—and all you had to do is keep unauthorized stuff outside your perimeter from gaining access to devices or data inside your perimeter. It’s not like that anymore, though. BYOD, mobile devices, cloud service, virtual systems and changes in attack techniques combine to create a scenario where it’s virtually impossible to assure security with any degree of confidence. At this point, it’s almost better to assume you’re compromised, and work from there to minimize the potential impact—especially when it comes to DevOps security.

Consider the fact that threats such as Stuxnet and Duqu were found to have been circulating in the wild for years before they were discovered. According to one recent study, it takes organizations an average of 256 days to discover a malicious compromise—in large part because they’re functioning from the semi-delusional mindset that they’re effectively protecting against such attacks. When you believe that your network is secure, you have no reason to dig deeper and scrutinize activity on the network to detect and identify suspicious activity.

Mitchell Hashimoto, co-founder and CEO of HashiCorp, is an evangelist for the idea of a zero-trust data center. Borrowing a page from the Ronald Reagan national security policy, Hashimoto stresses a strategy of trust but verify. He believes in a security mentality in which all resources are assumed to be compromised—particularly in organizations that have embraced DevOps.

DevOps brings much greater flexibility and agility, but with the more rapid pace of development and deployment also comes increased volatility and potential uncertainty when it comes to maintaining accurate visibility of the assets and data in the environment, and the vulnerabilities you’re exposed to. With the unprecedented scale and automation of modern data centers, the zero-trust model keeps infrastructure secure while still enabling automation.

“As the scale of modern computing continues to increase, our security mindset must change. Automation and DevOps help manage this scale, but introduce more change. With change comes vulnerability,” cautions Hashimoto. “The best way to approach this problem is to assume a zero-trust model. With this mindset, all resources are assumed to be compromised and require specific permissions to connect to other resources in the environment. If the permission policy does not match, the resource gets denied.”

The idea behind this zero-trust approach is to greatly reduce the number of opportunities an attacker might have to gain access, and reduce the scope of potential damage in the event of a successful breach of your network. Applying this concept at scale—in a dynamic DevOps environment—can be more of a challenge. So much changes so quickly that you need to have automated tools capable of managing this process. Attempting to do this with any sort of manual system would be lunacy.

If you still think there is an inside and outside to your network, or that it’s possible to win in a battle of us vs. them, you’ve probably already lost. There is no such thing as impenetrable security, and there is simply too much volatility in any network environment—but especially in a dynamic DevOps environment. Trust but verify. Embrace the idea of a zero-trust data center to improve your security and minimize the potential for attackers to access and compromise your network.

April 21, 2016
Security Breaks DevOps – Here’s How to Fix It
The concepts of communication, collaboration, abstraction, automation and orchestration are cornerstones of the rapidly growing DevOps movement. At the same time reliance on virtualized infrastructure and Infrastructure-as-a-Service has exploded, making manual provisioning and management simply not feasible anymore; it takes too long and locks up too many resources. Modern DevOps methods and tools have emerged, allowing IT organizations to move faster and with higher quality, thus giving them the ability to respond to the business with more agility.

Now security teams have an opportunity to learn from the DevOps experience. Manual policy provisioning and security operations in highly dynamic IaaS environments simply doesn’t work, for the same reason it doesn’t work for DevOps teams – the pace of change is simply too to fast to handle manually.

Applying security policies based on static parameters and making manual rule changes just before production leaves little time for provisioning the policies. This impacts release quality, increases risk of errors and slows down the DevOps cycle.

Trying to use DevOps orchestration tools to provision security can leave companies exposed since these tools lack critical controls and don’t integrate with the rest of the security infrastructure.

To solve these challenges, IT and security teams need to adopt platforms and processes that match the speed and agility of their DevOps brethren.

Here are the key ingredients you should look for in security solutions that can move at the speed of DevOps:
- Built-in Automation – Security automation means that any control (e.g. firewall policies, configuration vulnerability scans, intrusion detection, multi-factor authentication) can be deployed and managed without human intervention. Most desirable is full-lifecycle automation, in which policies are set once and tied to some context, after which underlying controls are 100% automated at each stage of the control’s lifecycle, from deployment to de-provisioning. Automated collection of audit and operational data is also critical, especially in environments where infrastructure components are only operational for short periods of time. Even though short-lived, these ephemeral resources are still in scope for auditor inspection, even if not running at audit time. Well-implemented automation enables security organizations to keep up with the scale and rate of change associated with dynamic infrastructure models. Security accuracy and effectiveness are both improved by automation, and potential for human error is removed—especially if API instrumentation enables cooperation of otherwise disparate technologies.
- Security Orchestration – Platforms that enable security orchestration centrally manage the composition, deployment, and management of individual control components into more complex, service-oriented security systems. By composing many individual controls into a larger system, security orchestration is considered to be a higher order function than simple control automation. In many implementations, orchestration also addresses licensing, metering, chargeback, and other security resource consumption issues that are important in service-oriented cloud computing and software-defined infrastructure environments.
- Instant Visibility & Continuous Enforcement at the Workload – Public clouds have no natural perimeter and network segmentation, which leaves individual servers exposed. In private clouds, malicious East-West traffic inside the network is undetected by perimeter tools and can become a serious threat. So choose a security platform that extends your investments in network security directly to the workload itself. The solution should be on-demand and easy to deploy. Many of these platforms have an agent-based model, so make sure the agent is ultra lightweight to eliminate drag on the virtual server, is non-intrusive to the workload and is easy to integrate into DevOps continuous deployment model. The agents should be deployable through orchestration tools, with scripts or manually, even on live systems without reboot, to speed up the process even further.
- Flexible Policy Definition – A modern security platform should allow security policies to be defined by logical application groupings instead of static network parameters, which protects new workloads automatically and overcomes natural limitations of traditional network security tools.
- Security at Every Stage – The DevOps model has multiple stages, many of which are conducted on various cloud services and on other virtualized architectures. This leaves assets vulnerable to attackers, so baking in security at each stage prevents this issue. Just as importantly, development teams need to know how security will impact the application being developed, so incorporating security early in the process makes a ton of sense.
- Layered Approach – Having a platform that provides layered security (not just a firewall) in the DevOps model, is key. Integrating multiple functions from different vendors would prove enormously daunting from an orchestration perspective. So make sure layered security functions like file integrity monitoring, security configuration monitoring, strong access control and vulnerability management are baked into a single platform and included on every system throughout the lifecycle.
- Seamless Integration with Orchestration Tools – Make sure your security platform integrates seamlessly with the orchestration tools you’re already using. Jumping back and forth between tools can slow things down, introduce errors and lower your overall security posture.
By implementing a security solution that incorporates all of these attributes, IT can bring security into the high speed, high quality DevOps model that is now required to provision and manage modern infrastructure.

About the Author/Amrit Williams

Amrit Williams is the CTO for CloudPassage. Previously Amrit was the Director of Emerging Security Technologies and CTO for mobile computing at IBM. Prior to IBM, Amrit was a research director in the Information Security and Risk Research Practice at Gartner, Inc. where he covered vulnerability and threat management, network security, security information and event management, risk management, and secure application development. Previously, Amrit was a director of engineering for nCircle Network Security, and undertook leadership positions at Consilient Inc., Network Associates, and McAfee Associates.
July 8, 2015