Category: DevSecOps

  • DevOps Chat: Aqua Security Seeks To Secure Containers

    DevOps Chat: Aqua Security Seeks To Secure Containers

    The migration to container-based application infrastructures is accelerating at a faster pace even than we saw with hypervisor-based infrastructure 18 or so years ago. Hand in hand with this is the race to provide better security solutions that are native to and purpose-built for containerized environments. Aqua Security has established itself in the container security arena, recently raising $25 million in capital funding as it seeks to lock down the container security market.

    In this chat, we sat down with Rani Osnat of Aqua Security to discuss the recent funding round and the state of the container security market. Below is the streaming audio of our discussion. Below that is the transcript of our discussion.

    Audio

    Transcript

    [su_pullquote align=”right”]Rani Osnat[su_custom_gallery source=”media: 1739530″ width=”100″ height=”100″ align=”center”]
    Rani Osnat has more than 20 years of enterprise software industry experience, in project management, product management and marketing, including a decade as VP of marketing for innovative tech startups in the IT security and cloud arenas. Previously Rani was a management consultant in the London office of Booz & Co. He holds an MBA from INSEAD in Fontainebleau, France. Rani is an avid wine geek, and a slightly less avid painter.[/su_pullquote]

    Alan Shimel: Hi, everyone. This is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard, and welcome to another chat.

    Today’s guest is Rani Osnat, VP of Marketing for Aqua Security, one of the leaders in the container security market, and Rani, welcome to our DevOps Chat.

    Rani Osnat: Thank you, Alan. Thanks for having me.

    Shimel: Thank you. Thank you for being here. So, Rani, the big news out of Aqua recently is, by anyone’s yardstick, a large raise of capital to fuel Aqua’s continued growth.

    Osnat: Yep, that’s correct. We raised $25,000,000.00 in a series B round led by Lightspeed Venture Partners, which is a very well-known tier one VC.

    Shimel: Yep.

    Osnat: And, it’s—well, to the best of my knowledge, it’s the biggest funding round in our space in continuous security to date, and it also brings total funding for us to $38.5 million.

    Shimel: That’s fantastic.

    Osnat: So, we’re, I think, in a pretty good position to capture what we think is a tremendous opportunity in this market.

    Shimel: Sure. And so, Rani, we were talking off mic prior to recording today—you know, beyond the sheer magnitude of the number, right, 25 is a big number, 38 is a bigger number—but beyond that, there’s also the validation. Which is, you assume a company like Lightspeed Ventures, Microsoft Ventures is another investor in the company, Shlomo Kramer, of course, from Check Point is another investor. You would assume these people are pretty bright people and they don’t throw their good money away. That, if they’re investing this money, they invest it for two things. No. 1, they see the opportunity in the market, so the market itself is ripe and worthy of that sort of investment. And then No. 2, that the team and the product at Aqua are also worthy of the investment.

    Let’s first talk about the market, if we can, though. I mean, so this is a validation, I think, of the container security market, if you will, right?

    Osnat: Yeah.

    Shimel: The containers are real, that securing them are real, and there’s gonna be a big market for that coming up. What do you think?

    Osnat: Yeah, I mean, definitely, when we started Aqua just under two years ago, we didn’t quite know how fast the market would move and what kind of market it would shape up to be. And fairly early on, even when we were in beta in early 2016, it became fairly obvious that this is an enterprise market. That is that, you know, some of the biggest adopters of container technology are not just Silicon Valley startups or web-scale companies that kind of invented this, but Fortune 500 enterprises across verticals like financials, insurance, retail, aerospace, manufacturing, and so forth, as well as government.

    And so, paradoxically, you would expect this kind of new technology to be first adopted by startups, but the real boom in adoption comes from the fact that enterprises are adopting it very quickly, and I think there are several reasons for that. One is that the benefits of using containers are overwhelmingly positive, and the benefits are pretty immediate. So, you can see benefits in agility in terms of how fast you can deliver applications to the market, you can see benefits in moving to the cloud, and reducing your infrastructure costs and operational costs. And you can see much better control over what kind of applications you’re deploying, where, and when, et cetera, largely through automation.

    So, these benefits are overwhelming, and additionally, containers are easy, right? So, it’s—you know, one of the things that made containers, which in itself is not a new technology, it’s been around for a while, but what companies like Docker did is make containers very accessible and very usable. And so, the fact that they’re easy to use makes adoption easy as well, and you know, you kind of see a pincer movement of, on the one hand, grassroots adoption through developer and DevOps teams of containers, so they develop applications using containers. And on the other hand, you’re seeing a top down approach of, you know, CIOs, CTOs seeing the benefits of containers, adopting them, or mandating their use for, for example, cloud native applications to drive cloud usage, hybrid cloud, cloud migration—all of those good things.

    Shimel: Absolutely. So, Rani, you know—granted, I’m not as involved in container and container security as you are, obviously, but to me, a couple of different thoughts. Number one, in my limited—granted, limited expertise, containers aren’t that easy, right? I mean, I think when we talk about containers and then, like, Kubernetes and stuff to manage the whole environment—for someone who hasn’t developed on them before and is used to developing, let’s say, in VMware or in Bare Metal, there is, there’s a learning curve. Maybe once you pick it up, it’s easier.

    But the other thing is, I always try to compare sort of container adoption, let’s say, to hypervisor adoption or VMware adoption, and I would say that containers, their adoption curve is higher or steeper, faster than sort of hypervisor’s.

    Osnat: Yeah, that’s correct.

    Shimel: And really what I see, the last couple—you know, we’re always doing surveys here at devopsy.kinsta.cloud, announcing the new Security Boulevard site—what we’re seeing is, you know, we always saw people messing with the containers, right? R&D testing, what have you—but the numbers of containers, the percentage of companies that have containers in product deployment, you know, in real, frontline stuff? Where it was—jeez, just two or three years ago was low teens, below 20 percent—is now climbing, getting near that critical mass number, right, of 50 percents and stuff like that. And that’s huge, right? You’re talking about early adopters moving to mainstream in a matter of months, and that’s —

    Osnat: That’s correct.

    Shimel: — that’s the numbers you see as well?

    Osnat: Yeah, we see that. And again, I don’t think this would’ve been the case if containers weren’t easy, as I said. I mean, there’s always a learning curve with new technology, but I think if you’re a new developer, a new programmer working today, working on a greenfield application, there’s really no reason for you to use something that is not containers unless it’s something obscure for technology reasons.

    But mostly, it’s a much easier way to develop applications quickly than previous approaches. And I think, you know, if we take a broader picture, a container is—this adoption of containers does not occur in a vacuum, and we actually see a convergence of three trends that are kinda coming together and containers are probably the biggest enabler of those three trends. And these trends are happening independently of each other. So, you know, one trend is one that you are very familiar with, it’s the name of your site, is DevOps, you know, the proliferation of DevOps as a method, process, organizational philosophy, et cetera, which is all about delivering applications faster and in a more continuous way, and containers make that easier than before.

    Another trend is the move to microservices architectures, you know, for web applications or cloud native applications, which is basically adopting what web scale companies like Facebook and Twitter and Netflix started, and now bringing into the mainstream. That, too, is facilitated to a great degree by containers, because implementing microservices as containers is, today, probably the easiest method of doing that. I mean, there are the so—called serverless architectures, et cetera, but they’re much less mature than containers are at the moment. Not that containers are super mature, but they’re more mature.

    And the other aspect is the whole kind of hybrid cloud, cloud native movement where, you know, it took 10 years, but enterprises are adopting cloud services in a very big way, including industries that you would never dreamed of having on the cloud, on the public cloud, like pharmaceutical, health care, insurance, banking, federal, and so forth.

    So, all of these—and again, containers, because they’re portable, because they can run anywhere in the same way, they’re a really good way to realize this notion of hybrid cloud. For example, we at Aqua have a customer—who, unfortunately, I can’t name, but it’s a well-known company. And they are, for them, this is already a reality. They are deploying applications on both Amazon and Azure using the same framework, using the same security policies, and in a way that makes these clouds interchangeable for them, so they can run application A on Azure today and they can run the same application on Amazon tomorrow. So, that’s a real change that we see, and containers are a big part of that.

    So, all of these things together, I think, are what’s driving this adoption. And yet, you know, I think we have to distinguish between adoption and penetration or, you know, maybe some other word. But the fact is that today, if you look at the total workloads that enterprises are running, containers are a very, very small percentage of that. But, if you look at any new applications delivered over the next five years as well as looking at migrating legacy applications to the cloud, you’ll see this number growing exponentially over the next few years.

    So, yes, in terms of the number of enterprises now either looking at, working with, or already deploying containers, that number is growing very fast, and I think there’s probably hardly a large enterprise on the planet today that is not at least thinking about containers if not already using them. But at the same time, you know, it’s early days for them. Most of them—not all of them, but most of them, the vast majority are looking at the first few applications being deployed, and this is just the first drop of rain before the deluge. So, it’s gonna be a lot bigger.

    Shimel: Yep. Rani, a couple of comments, questions, follow ups. So, first of all—yes, DevOps, containers, they seem to go like peanut butter and chocolate. Again, so does microservices and containers, but to me, I—you know, when I was a kid, a teacher once taught us that all spaghetti is macaroni, but not all macaroni is spaghetti.

    Osnat: Sure.

    Shimel: So, it almost seems that, you know, wherever you see containers, you see microservices, but you don’t always see containers when you see microservices, right? In some regards, microservices can be even bigger, right? It has even more of a use footprint. Actually, on devopsy.kinsta.cloud, we’re launching a microservices channel which we hope will eventually grow into a standalone site, because I do think microservices is that big and has the potential to be that big.

    Osnat: Yeah, but microservices is not a technology; containers are. Microservices is an architecture, you know what I’m saying? There’s a difference.

    Shimel: Yeah, fair enough. Yep. But, you know, bringing it back—and, of course, loud usage and all of that. But, let’s turn for a moment and talk about the mission of securing containers and all of these architectures and platforms and so forth. That’s really what Aqua is, and when we talk about why they invested money, these investors, not just because the containers are so big, but because the mission of securing them is also big.

    Osnat: That’s true. So, yeah, I mean, when you look at—so, first of all, we’re not really, I mean, the fact that we’re a container security company might allude to the fact that we secure containers. That’s not exactly true. So, you know, we don’t look to secure a container or containers, we look to secure the workloads or applications that are running on containers.

    Shimel: Mm-hmm.

    Osnat: And that’s a difference. Because—and again, here, there are several trends that come into play. One is really that these things that I mentioned before, the DevOps trends, the microservices, architecture, and moving to the cloud, they also affect how you can and want to do security. You know, if we look at the cloud first—when you go to the cloud, a lot of the basics, you know, the bread and butter security that you use to invest in as an enterprise disappears. Why? Because these are services that are already taken care of or provided by the cloud service provider.

    So, you know, when you run your applications on Amazon, you don’t really have to worry about things like data center security, infrastructure security, network security to a degree, identity management to a degree. And so, a lot of these things are—you know, they’re basically taken care of for you. So, the focus shifts to the application layer, and that is one aspect.

    Another aspect, which is a really positive one for using containers, is the fact that, since you are now breaking up the application into a bunch of microservices, you can have much more visibility and control into what the application is doing. You know, if you look at an individual container or microservice, it’s much easier to understand the intended function of that container or service, and consequently, be able to understand what is considered good behavior, and be able to identify pretty easily what is bad behavior. And you do that at a very granular level.

    Additionally, if you look at the networking aspect, in a way, the networking has been brought into the application in a more visible way than before. Before, you could have things done within the application that maybe a malicious actor did within the application, and it’s all done internally, and it’s a black box. You don’t have visibility into it until it actually gets out.

    With microservices, you are able to see the interaction between the different components of the application, sometimes at a very fine grained level and, again, be able to identify any kind of weird or abnormal communication between, you know, parts of the application that are not supposed to be communicating that way. So, that’s another benefit. So, these things really allow us to have much more control and visibility over what the application is doing.

    The last piece is around DevOps, which is often nowadays coined as DevSecOps, which is the whole notion of shifting left security—i.e., bringing some of the control points not to the run time environment but to the developer environment. And why is that? Because containers are also immutable, right? So, if you’re using containers directly, you’re not supposed to see any change in one time environments. You’re not supposed to see patching, nobody is supposed to SSH into your host that’s running containers, it’s supposed to be entirely orchestrated and automated.

    And so, anything that happens there is by definition not good. But, at the same time, you have the opportunity to make the application more secure from the start, which is in the development phase, and that includes things like, you know, removing vulnerabilities, ensuring the configuration is correct, enforcing best practices. And if you can automate that—which we do—then you’re winning, right? Because you’re delivering a much more secure application to start with, you’re gonna have a smaller attack surface, and then in run time, all you need to do is make sure that there is no drift or no unexpected changes to the run time environment, which would be considered malicious or at least suspect.

    Shimel: Got it. So, Rani, we’re running a little low on time. We’re actually out of time, but let’s keep talking. [Laughter]

    Osnat: [Laughter]

    Shimel: So, now, we’ve got—what are you gonna do, how are you using the 25 million? What’s the plan?

    Osnat: Right, so you know, in our short life of two years, we managed to launch the product very early and get quite a few enterprise customers, many of them Fortune 100 customers across many industries, and that sort of traction is what really made Lightspeed and the other investors invest in us, and we need to continue this. The market is growing, right? As we mentioned, adoption is growing at an accelerated pace, so we need to be there.

    That means, you know, investing in the quality as well as the breadth and depth of our solution. There is—containers are not a singular technology. I mean, there’s a lot of variation in the stack, not just in orchestrators and OS’s, but in the container engines themselves, and this will become even more so over the next few months as things like, you know, additional run time engines are introduced, and not just the Docker open source run time engine.

    And so, this requires investing in the right technologies and making sure that we can fulfill the requirements of our customers and, additionally, of course, we need to expand our presence, both in the U.S. as well as in other parts of the world.

    Shimel: Let me talk to you about that a sec, Rani. So, I’m gonna assume U.S. probably represents at least 50 percent of your market, is that about right?

    Osnat: That’s correct, yeah. [Cross talk]

    Shimel: And probably Ameya the lion’s share of the rest.

    Osnat: At the moment, yes, but Asia is also growing, you know, there’s—

    Shimel: I also wanted to ask—what about AP?

    Osnat: Yeah, so Asia Pacific is growing as well. There are a lot of container users in places like Australia, China, Japan, and so forth. And so, this is—these are obviously big economies, there are big companies there. They’re as advanced in terms of cloud adoption as the U.S. in some cases. So, we need to be there.

    Shimel: Absolutely. Well, how do you—so, I was actually out at RSA APJ this summer, and it was in Singapore. And, you know, I had a chance—I actually put on a DevSecOps event there with RSA. So, I had a chance to talk to many of the RSA attendees, some of the vendors and stuff.

    I mean, what’s interesting there is, your infrastructure, you know, even in Europe, AWS is an 8,000-pound gorilla, right?

    Osnat: Correct.

    Shimel: Where do you—we don’t see that in Asia Pac. AWS is still a player, obviously, but there are other solutions there.

    Osnat: Mm-hmm. Yeah, that—

    Shimel: Go ahead. How does that affect you guys, or how do you deal with it?

    Osnat: Well, it affects us partially because mostly, you know, we’re pretty much cloud agnostic, right? We run on all the major clouds. It’s not a major effort for us to run on additional clouds. You know, even today, we support Amazon and Azure, Google, IBM Bluemix. And so, it’s relatively easy for us to support additional clouds, and it’s not a—that’s not the stumbling block, in most cases, right? It’s more like things like esoteric OS’s or weird configurations that we encounter sometimes. But, in most cases, that would not be an issue. Not to mention that a lot of companies are also running private clouds, using VMware or other types of virtualization infrastructure. So, that is really not a stumbling block for us, at all.

    Shimel: Good, good. Interesting. Rani, as I said before, we’re way over time, I need to wrap this up. But, first of all, congratulations on the raise. I’m sure Aqua has 25,000,000 good uses for this money as well, and we’ll see more coming down the pipeline in terms of both functionality products as well as reach around the world. You know, always good to have you on, you have a great handle on where the container market is and of course where the container security market is.

    So, thanks for being our guest today. We’ll have you on again soon.

    Osnat: Thank you.

    Shimel: Thank you. This is Alan Shimel for DevOps and Security Boulevard Chats. Thanks for listening. We’ll hope to see you soon on another chat. Bye bye, everyone.

    — Alan Shimel

  • Standardizing a Process that Drives Secure-By-Design

    Standardizing a Process that Drives Secure-By-Design

    In “Building Security into Code + Culture,” I described how our culture of coding is predicated on chaos, and the critical challenge for organizations is to establish the right mix of processes and tools that support a smarter, risk-based approach to development. A key aspect of this strategy is, of course, to implement a sense of order within the chaos that enhances security without hindering the speed of innovation.

    I overviewed a number of different recommendations to approach secure by design, such as making code more mature and baking in security measures and privacy/contractual compliance from the start. I also emphasized that organizations should tackle the rules, tools and fears pillars that help shape the culture, as each of these can be transformative in helping people use the right approach or method. Making the rules and defining fears is relatively straightforward, and with the right degree or training and awareness your organization can adapt.

    But what about tools? The right tools can do wonders to “force” people to use better, smarter, more secure methods—that is, if such tools exist. Though I have not done a deep dive into whether there are any robust development tools integrated with security software, I’m a realist and will go out on a limb to say none of them have reached maturity just yet. In light of this, it’s essential that organizations focus on standardizing the overarching process that will enforce privacy and security by design, development and deployment.

    The first thing to do is set the business drivers behind the process from a legal standpoint. Gather and research the privacy regulations and compliance requirements that affect your organization. Analyze and then translate these using a risk-based approach to security controls requirements, and then publish these as an awareness catalogue available to all developers across your organization. You should also ensure that training is available, on-demand and on a just-in-time basis, for any developer on any desired control.

    Next, set the technology drivers by prescribing to secure coding practices defined by the industry, such as the Web Application Security Consortium (WASC) – Threat Classification system (based on Open Web Application Security Project [OWASP] Top 10) and SysAdmin, Audit, Network and Security (SANS) Top 25 (which are based on the Mitre – Common Weakness Enumeration [CWE]).

    At this point, you must ensure that all your applications and systems comply with the security controls requirements catalogue you created. These can be batched into smaller parts that are handled by developers or teams of developers, all of which use your security controls requirements catalogue and industry-standard secure coding practices. Again, you’ll want to make sure that training sessions are available on a just-in-time basis for any developers who need them!

    Upon completion of each section or unit, code must be validated and verified for trust. Peer code review is the first step—have your developers present their work and provide the logic to a different team of developers. You can always employ static code analysis to scan code for any weaknesses, defects or violations of best practices, and subsequently enter the bug fix stage if any are detected.

    Then, you can merge the code branches into the main and compile for run time, so you can conduct live vulnerability scanning and penetration testing. Again, these should be based on the industry-standard secure coding practices adopted across your organization. At this point, you should be able to establish reasonable assurance for the release version of your application or system by having published artifacts for review by entities such as auditors or clients.

    Continuous improvement will require adding new features and subsequent emphasis on the validation and verification process. I would also recommend repeating the entire process from start to finish on a regular basis to reinforce the process, perhaps annually or semi-annually. And of course, if there are any major changes or shifts (as there are likely to be) in your privacy regulations, compliance requirements or secure coding practices, this will absolutely need to be addressed at the organizational level so your process addresses these head-on.

    Privacy and security are such important topics today because they are an artifact of the youth of the computer software industry. If this industry was more mature, then the outcome would be quality code. For some reason, it’s okay to create buggy, weak and inadequate software in a world in which we wouldn’t tolerate buggy, weak or inadequate cars, airplanes, bridges, buildings … and the list goes on. And the reason for this is pretty obvious: People are acutely aware that cars, airplanes, bridges and buildings put their very lives on the line, whereas software “just” makes them susceptible to things such as identity theft and ransomware.

    This is the message we’re sending: It’s not OK to kill people, but it’s perfectly acceptable to ruin their lives. This is not OK! It’s time for organizations to standardize the processes that drive secure-by-design, and embrace necessary and fundamental changes to how we approach development. As developers and IT professionals, the onus is on us to shape a better world driven by quality software.

    About the Author / Robert Hawk

    Robert Hawk is Resident Security Expert at xMatters. He has extensive experience in Information Systems Security, Computer Security, Cyber Security, Information Assurance, as well as Governance, Risk, and Compliance (GRC) Management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI, and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

  • It’s Time to Break Up with Your WAF

    It’s Time to Break Up with Your WAF

    If the only reason you have a web application firewall (WAF) is for compliance, you deserve better. It’s time to replace it with something that provides not only compliance, but real security value as well.

    In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this: The WAF survived not by being excellent, but by being mandated.

    The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.

    Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.

    At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer—a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.

    PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value—they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.

    And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are four more reasons why WAFs should be replaced.

    The Minimum WAF Rules Approach is Broken

    A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing—what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.

    To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.

    Learning Mode is Broken at Speed

    One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.

    Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.

    When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.

    Monitoring Mode Really Isn’t Compliance

    The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.

    Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.

    Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.

    CDN-based WAFs Were for Convenience, not Effectiveness

    The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).

    For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.

    If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.

    Achieve Compliance and Real Security at Speed

    If this article sounds a little too familiar—if all you’re getting from your WAF is compliance—then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time—for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.

    Don’t settle for compliance alone. You can achieve both compliance and real protection—and that’s what your business and your customers deserve.

    — James Wickett

  • Building Security into Code and Culture

    Building Security into Code and Culture

    Organizations tend to have a very predictable approach to security: reactive. Most don’t really care about security until something bad happens. But with data regulations and requirements becoming more rigid around the globe and cybercrime only continuing to escalate, the notion of security as an “add on” or an afterthought is quickly becoming outdated. Today, an organization without adequate security measures is like a skydiver without a parachute—sure, the parachute doesn’t guarantee a 100 percent safe experience, but wouldn’t you rather have one than go without?

    A big problem, however, is that the modern approach to security remains inadequate. Most companies simply layer piecemeal measures over their existing infrastructure, not realizing that this isn’t an effective way to mitigate risk. Instead of adding on bits and pieces of security such as firewalls and antivirus programs, organizations should strive to incorporate security principles into the very foundation of their IT, in both the code and the culture.

    This is what Microsoft sought to do with its SD3+C principles, e.g. Secure by Design, Secure by Default, Secure in Deployment and Communications. While all of these are designed to impose better security measures throughout the development process, the first two arguably provide the highest security benefits. This is because they prevent the introduction of vulnerabilities in the first place while minimizing the potential exposure of software—so-called “attack surfaces.”

    Security and safety by design has thus far achieved greatest maturity in the automobile industry. Modern-day cars have more than 100 different safety and security features, including redundancies, and are rigorously tested for verified assurance. While crash tests destroy vehicles and take time to conduct, they ultimately teach us invaluable lessons that make them 100 percent worth the investment.

    Baking security measures into design and development is likewise a better approach when it comes to code, but it presents a problem: Developers, by nature, don’t want to take the time to build safety nets. A major criticism of SD3+C is that it slows down innovation by forcing developers to make more considerations than “make something really cool at lightning speed.”

    This reaction isn’t surprising when you consider the culture of coding, including the process by which we teach new developers. Hacker culture has long carried a certain kind of allure, romanticizing the role of the developer as a creative, clever and adventurous rogue. It elevates those resourceful individuals that can overcome software challenges in the fastest, nimblest, slickest way—not necessarily the securest.

    It’s never been the standard to teach the morality, ethics or laws of coding; instead, we teach people how to code and let them take off running. But the modern digital age has required us to put the brakes on and rein in that spirit. It’s like teaching someone to drive a Ferrari at breakneck speeds but not about the rules of the road, and then later expecting them to steer within the lanes, stop at red lights and not exceed speed limits.

    Bring Order to Code Chaos

    Our culture of coding inherently perpetuates chaos, but now we need to implement some degree of order, and this is a tough challenge. We need to drive a risk-based approach to development that introduces order into chaos without hindering innovation.

    How do we begin to accomplish this? The first thing to consider is changing how you approach code in the first place by making it more robust. Typically, code can’t be easily changed once it’s written; a single line may be easy to manipulate, but at several million lines, you risk severing the ecological connections that make the app work, and changing any one piece could break the entire application. With your code in such a susceptible state, it’s far too resource-intensive to maintain.

    The solution is to make it more mature in the first place. Make your code modular enough so that it can be amended in part when necessary, and then you can easily bake in additional security measures and eliminate dependence on firewalls and antivirus as your first (or only) line of defense.

    Second, consider the privacy law and contractual requirements of your organization, and address them directly in your code from the start. Understand that different types of privacy data will need to be handled differently and require different levels of protection across technical, physical and administrative dimensions. Whether you deal with payment card industry (PCI) or protected health information (PHI), you should be intimately familiar with the standards governing the protection of data your organization deals with.

    Now, what about culture? In its simplest essence, we can think of culture as comprised of three basic factors: rules, tools and fears. Where rules exist, you should apply them; where tools exist, you should use them; and as an organization, you should be “afraid” of the same things, because common fears tend to be strong motivators for groups of people or the masses. The only re-transmission of culture is through awareness, training and immersion.

    An important point I invite you to consider is that human beings won’t do anything without a reason, whether real or imagined. Humans are experienced-based learners not knowledge-based learners. For this reason, we learn valuable lessons from mistakes and failures. An important aspect of this is timely communications. When something has gone wrong we need to be able to get the right people on task to work toward planning mitigations, learning lessons and making things better.

    One way to effectively change or reshape your culture is to enforce the rules—for instance, the new General Data Protection Regulation (GDPR) mandates severe fines and consequences for PII data breaches (which is, in fact, similar to penalties enacted by the auto industry years ago).

    Another is to provide better tools and processes that essentially “force” (or, more kindly, compel) your team to use the right approach or method.

    Finally, you can employ fear, uncertainty and doubt, otherwise known as “FUD.” Though it may sound a bit sinister, FUD can be a very effective way to govern—although on its own, it’s a very tenuous and fragile kind of power. This is why you balance it with rules and tools, so that the overarching objective will resonate in both the hearts and minds of your team: Keep your organization happy and healthy.

    Because this is the reality that modern digital organizations must face: It doesn’t matter how innovative or bleeding-edge you are unless your business stays healthy! A tree that is well-rooted and cultivated to grow properly and upright will weather the worst storms, and ultimately live a long and prosperous life. Remember that Ford once had to introduce critical safety measures to the Model T, and nobody was worried about hydraulic brakes, seat belts and padded dashboards slowing us down.

    About the Author / Robert Hawk

    Robert Hawk is Resident Security Expert at xMatters. He has extensive experience in Information Systems Security, Computer Security, Cyber Security, Information Assurance, as well as Governance, Risk, and Compliance (GRC) Management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI, and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

  • Executive Buy-in May Be Preventing DevOps Success

    Executive Buy-in May Be Preventing DevOps Success

    A common misconception in the executive suite is that an organization can reap all the benefits of DevOps without fully embracing the change necessary. That’s understandable, given that a DevOps transformation is a lengthy, costly disruption for companies of all sizes. DevOps requires businesses to transform, from team organization to culture to development processes. This shift often sparks reallocation of power and influence, which sometimes can make high-level executives uncomfortable. While most companies have begun to recognize the overall business benefits of DevOps, few are fully committing to such a large undertaking. As a result, a hesitant executive suite holds an organization back from realizing the full potential of DevOps.

    The key to successful DevOps implementation has four facets. Executing against one element just isn’t enough—an organization must combine all of them to realize the benefits of DevOps:

    • Training: Once executives have educated themselves on the importance of DevOps and accepted the disruption that comes with it, they must make sure the individuals are properly trained. Everyone involved needs to be open to learning new skills and new ways of functioning. A big part of DevOps is breaking down team silos, so individual contributors need to be willing to work across functional boundaries.
    • Tools: DevOps adoption can be viewed as a cultural and methodological change, and therefore teams also need the right tools that help them work together to create scalable and secure applications efficiently. The executive suite should invest in platforms that support automation and collaboration.
    • Support and determination: To provide support and guidance throughout the shift to DevOps, organizations should consider hiring a DevOps expert or bringing in a third-party consultant. This person can help the executive suite map out a DevOps strategy and help train the teams involved. Lack of expertise is one of the reasons businesses often fail to complete a DevOps transition.
    • Cross functional and accountable teams: A DevOps team should have all of the resources necessary to implement and deliver functionality to the customer. They should also be accountable for operating and supporting it.

    Another important consideration is security. The CISO and security team are responsible for security in most organizations, but developers need to understand the critical role they play in creating secure applications. They need to be accountable for the security of the software they write. It’s up to the security team to train and nurture them until they are self-sufficient. The development organization as a whole must be willing to make security part of the annual goal-setting process and to report on progress transparently at each level of management.

    Every DevOps implementation begins with education, from management to the individual contributor. Educational resources increasingly are available as DevOps continues to gain momentum in the industry. If faced with a hesitant executive suite, teams should leverage proof points from other companies that have successfully implemented DevOps. Leadership should be ready to measure, experiment, iterate and, most importantly, stick with it. When armed with the right training, tools and support, organizations can gain a competitive edge with DevOps.

    — Pete Chestna

  • DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    The evolution of DevOps is by no means done, but it’s safe to say that there is enough agreement and acceptance to declare it a hero. DevOps has helped glorify IT to the point where it’s no longer preventing business, nor a provider nor a partner of the business.

    Often IT is the business, or its vanguard for competitive disruption and differentiation.

    Splintering the success of this portmanteau hero, we now hear more and more of two trusty sidekicks: DevSecOps and DevNetOps. Lesser known in their adolescence, these tots are still frequently misunderstood, are still forming their identities, and still need a lot of development if they’re to enter the IT hall of fame like their forerunner.

    Just as the terms look, DevSecOps and DevNetOps are often assumed to be about wrapping DevOps principles around security and networking: operators hope to assuage technical debt and drudgery by automating in proficiency and resiliency. For networking, I’ve covered how there is a lot more to that than coding, but to be sure, these sidekicks certainly espouse operators learning how to do develop while DevOps was equally, if not more, about developers learning to operate.

    The Shift Left: SecDevOps and NetDevOps

    As if it wasn’t hard enough to tell what DevSecOps and DevNetOps want to be when they grow up, we’ve gone and given them alter egos: SecDevOps (aka “rugged” DevOps) and NetDevOps. Think about them exactly as the words look—it’s about the shift to the left. Left of what?

    Traditional DevOps practices focus on business-specific applications development. The development timeline is known as a concept to cash, and with all the superpowers of DevOps we try to reduce our enemy—the lead time and repeatable processes between code and cash.

    Security and building infrastructure, like networks, were considered supporting tasks, not revenue-generating nor competitive advantages. Thus, security and networking were far to the right on the timeline with concerns that deal with operational scale, performance and protection.

    Today’s shift left propels security and infrastructure considerations earlier down the timeline, into coding, architecture and pre-production systems. It’s a palpable penny-drop amid daily news of security breaches and infrastructure outages causing technology-defined establishments to bleed money and brand equity.

    Fill the bucket with cash, but don’t forget to forestall the leaks!

    DevOps and Infrastructure: Challenge and Opportunity

    Automation sparks have flown over the proverbial wall into the camp of I&O pros. Operators trading physical for virtual, macro for micro, converged for composed, and configuration for code is proof that the fire has caught security and networking. Controlling the burn now, is key, so that healthier skills and structures arise in place of the I&O dogma and duff. Fortunately, this is precisely the destiny for our newfound heroes, DevSecOps and DevNetOps.

    However, doing DevSecOps and DevNetOps, embracing security and networks as code, we mustn’t be so credulous as to forget the formidable DevOps practices and patterns that need transforming along the ultimate automation journey. Testability, immutability, upgradability, traceability, auditability, reliability and other you-name-it-abilities are not straightforward to achieve.

    Discounting “aaS” technology consumed as a service, a fundamental challenge to innovating SecOps and NetOps, compared to application ops, is that applications are crafted and built; security and networking solutions are mostly still bought and assembled.

    Security and network infrastructure as code is something that needs to be co-created with the vendors. Other than in the cloud, it will take a while before security and networking systems are driven API-first, and redesigned to offer simulation, finer disaggregation into microservices, and orchestration with scale and resilience.

    While this will land first in software-defined infrastructure, there is still a way to go to manage most software-defined security and networking systems with continuous practices of artifact integration, testing and deployment. Hardware and embedded software will be even more challenging.

    Finding Strength in Challenge

    So on one hand, DevOps is evolving with security and networking shifting left. On the other hand, traditional security and networking ops are transforming with DevOps principles.

    Is the ultimate innovation to squeeze out those traditional operations altogether? Does NetDevOps + DevNetOps = DevOps?

    There is a parallel train of thought and debate, with success on both sides. Purist teams cut out operations with the “you build it, you run it” attitude. Other companies such as Google have dedicated operations specialist teams of SREs. While the SRE reporting structure is isolated, SRE jobs are very integrated with that of development teams. It’s easy to imagine the purist approach, subsuming security and networking into DevOps practices, but only if we assume the presence of cloud infrastructure and services as a platform. Even then, there is still substantiation for the SRE.

    Layers below, however, somebody still needs to build the foundations of the cloud IaaS and data center hardware. As they say, “Even serverless computing is not actually serverless.”

    Underpinning the clouds are data centers. And then there’s transport, IoT, mobile or other secure networks to and between clouds. In these areas, it’s obvious there is a niche for our two trusty sidekicks, DevSecOps and DevNetOps, to shake up ops culture and principles. These two heroes can rescue software-defined and physical infrastructure from the clutches of so many anti-pattern evils, like maintenance windows and change controls (ahem, it’s called a “commit”).

    We may not require rapid experimentation in our infrastructure, but we would warmly welcome automated deployments and updates, failure and attack testing drills, and intent-driven continuous response. They will boost resiliency and optimization for the business and peace of mind for the builders.

    Teams operating security, networks and especially clouds, need to honor and elevate DevSecOps and DevNetOps, so that on the journey now afoot, our teams and our new heroes may realize their potential.

    About the Author / James Kelly

    James Kelly is a lead expert architect on cloud and software-defined networking at Juniper Networks. He also serves as a private yoga instructor, and previously, he founded a capital management firm in Ottawa, Canada. Connect with him on LinkedIn and Twitter.

  • Software Security is an Engineering Problem

    Software Security is an Engineering Problem

    We live in a world where those who sell products are generally held accountable for defects. Automobile manufacturers, pharmaceutical companies and toy makers are among the businesses that have been handed fines and tarnished reputations for distributing items that were later deemed ineffective or dangerous.

    One notable exception to this “consumer first” ethos is the traditional shrink-wrapped software world, where responsibility for product problems is hazy. The vendors that develop and sell software and the customers who purchase and install that software are in a constant battle to shift security liability. The vendors strive as best they can to reduce and remove product vulnerabilities and offer secure configurations while customers deploy, configure and operate the software in very different environments, with very different configurations, which can produce very different security outcomes. Because no customer can (or should) assume receipt of 100 percent vulnerability-free software, they must always take on the primary burden of protecting the environments where that software lives to offset the risks—which typically falls to the customer’s IT and security teams.

    Although there are excellent arguments for both sides, the current situation leaves both parties wanting—and needing—a higher level of assurance in both the development and runtime settings.

    Software Delivery Has Changed (Along with Security Responsibility)

    The good news for software customers is that software delivery is rapidly moving away from an on-premises install approach to a cloud-based subscription model where applications are delivered via the internet. Upfront costs for hardware and software, as well as the expense of personnel to install and manage that software, are replaced with business-friendly, predictable, subscription-based operational costs. Software is easy to launch, upgrades are uncomplicated and scaling to meet changing business needs is simple.

    Customer expectations are high for software-as-a-service (SaaS) solutions. Purchasers demand an elevated level of innovation and want new features more often. They assume built-in support of global information security and privacy regulations such as the European Union’s General Data Protection Regulation (GDPR) and various U.S. regulations, including the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and PCI Digital Security Standard (PCI DSS). SaaS customers also expect the vendor to take on larger responsibility for any potential software vulnerabilities that might negatively impact the customer’s data and operation.

    The new reality is that deploying software in the cloud significantly changes the paradigm of how software security should be treated at the vendor level. This means companies now have to think critically about security as an engineering problem as the balance of the liability burden shifts focus to the cloud provider’s engineering practices to ensure constant delivery of a secure and trusted cloud service, rather than just secure software.

    Now is the Time to Rethink Software Security

    Cloud-based application delivery brings together under a single company umbrella the ones that make the software and the ones who run the software. Informing software development of runtime behavior and vice versa can have significant advantages in enhancing the overall security of the software by offering a closed-loop system. In such a perspective, the rapid pace of software releases work in favor of enhancing security.

    Shifting security to an all-around engineering responsibility requires the elimination of traditional work silos. Geared-for-speed developers must receive precise information early, allowing them to correct security problems during the initial coding process. DevOps team members also must assume security responsibilities. And security engineers who understand the attacker mindset, security risks and compliance requirements must provide guidance at all points in the software development process.

    Change is never easy in any organization, so transforming disconnected teams into one in which security is an across-the-board responsibility is difficult. Managers must be careful to not alienate team members who already have full plates. And although we’re starting to see some shifts in the educational model to one in which professionals are taught early on how to seamlessly integrate coding and security, we have a long way to go.

    While we wait, the most effective way to overcome the chronic problem of heavily siloed teams is to provide the entire software engineering team with a means to quickly identify issues between software development, its deployment and runtime across all the components. These tools must give users the ability to:

    • Scan and provide real-time analysis that integrates source code analysis and its runtime behavior. After all, they are two sides of the same coin;
    • Obtain accurate and full visibility into the security impact of changes from build-to-build;
    • Ease the audit analysis process;
    • Reduce the number of false positives; and
    • Allow developers, DevOps, and Security to collaborate to enhance the security of the environment.

    The goal? An ability to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process instead of post-deployment, when liability, revenue and reputational risks are the greatest.

    Consolidating today’s siloed security practices into an integrated engineering effort is the only way to ensure the appropriate level of security at the appropriate time in today’s fast-moving cloud-based software industry. This sort of shift in thinking and processes will give customers less security worries and better products. Development teams will become more effective and efficient. DevOps will have real-time visibility into how each release impacts the infrastructure. And Security will know how each release impacts both security and compliance requirements. SaaS companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and high levels of software security. It’s a win-win-win for everyone.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • DevOps, Security, AI Convergence on Horizon

    DevOps, Security, AI Convergence on Horizon

    DevOps is regarded as practice that can drive performance advantages. Artificial intelligence is showing very real promise across the security market. Most public and private-sector organizations know that they must explore new and different ways of defending their networks against modern threats. These three factors make it clear that DevOps, AI and security are ripe for convergence.

    Defining AI

    Anyone reading this post doesn’t need me to explain to them what DevOps and security are; both of these categories are well-defined. However, AI is really in an emergent stage, with different types in use and many definitions floating around. Because of this, I think it is important to let readers know that in this post, AI refers to a class of technology that can:

    • Consume data, learn and get smarter on its own
    • Automatically identify and solve problems
    • Operate independently, without human supervision
    • Scale massively
    • Move at near real-time speed
    • Achieve levels of accuracy that are beyond human capabilities

    DevOps and Security are United

    DevOps and security have merged. For several years now, organizations have been leveraging automation technologies and DevOps practices to continuously deliver security and compliance policies across data centers and clouds.

    Further legitimizing the union is the fact that leading DevOps and automation players such as Puppet, Chef and Ansible have formed numerous partnerships that deliver effective security capabilities to their customers.

    There are, of course, other signs that show how successful the DevOps and security marriage has been. One of which is the emergence of the term “rugged DevOps.” It is now so widely recognized that it commands its own section on this site and is often the subject of discussion at several notable security conferences.  

    DevOps and AI are Dating

    The relationship between DevOps and AI is in the early stages, with the courtship between the two well underway. Examples of its progress are found in numerous blogs and articles, several of which include:

    DevOps and AI have certainly not yet intertwined as deeply as DevOps and security have. These examples (and others out there) do show they the two will continue to integrate beyond what we are currently witnessing.

    DevOps, Security and AI

    DevOps and security are wed. DevOps and AI are moving closer toward each other. It’s only a matter of time until all three get together.

    Because several DevOps leaders are already in the business of security, it’s logical to assume that a partnership between one of them and an AI-driven security provider will be what ultimately leads to a marketable solution.

    DevOps provider candidates with the potential to move on a partnership that can combine DevOps, security and AI have a raft of new and established security providers available to work with. Several of the startups in this class are recognized in the CB Insights AI 100 2017 infographic. Companies such as Cloudera (NYSE: CLDR), which is using AI and machine learning to solve security problems, are among the more established providers that may make for a perfect partner. 

    How quickly will the market see such a partnership? That remains to be seen. However, with DevOps now fully accepted as a methodology that can positively impact bottom lines, AI coming into its own, and the need for new and different ways of defending organizations against attacks at a critical stage, it seems almost certain that the convergence will be upon us sooner rather than later.

    — Joe Franscella

  • Amazon’s Macie: Machine Learning to Protect Data in AWS

    Amazon’s Macie: Machine Learning to Protect Data in AWS

    Macie is a recently launched security service from Amazon for its AWS customers. It works by identifying and classifying sensitive data such as personal information or intellectual property, continuously monitoring that data for anomalies and giving customers detailed alerts and dashboard readouts related to the access or movement of the data. Macie is currently able to protect data stored in Amazon S3, and support for additional AWS data stores will be available later this year, according to AWS.

    Netlix is an early adopter of Macie and so far has seen good results. “Since we started using Amazon Macie we’ve found that it is flexible enough to solve a range of information security challenges that would have previously required us to write custom code or build internal tools, helping us move fast with confidence,” says Patrick Kelley, cloud security engineer at Netflix.

    In addition to Netflix, Amazon lists Autodesk and Edmunds as early users of Macie.

    Amazon claims that Macie uses machine learning to automate the process of discovering, classifying and protecting data stored in AWS. Macie starts out by creating a baseline of data access behavior and then monitors for actions that might indicate risk, such as large quantities of data being downloaded, sensitive data being configured to be externally accessible or credentials being stored insecurely. Macie provides a console front end. It also delivers alerts and recommendations on how to strengthen your security.

    The results of Macie’s analysis of your data may help you better understand where sensitive information is stored and how it’s typically accessed, including user authentications, locations and times of day. It can identify data with high business value, including programming languages to detect source code, logging formats, database backup formats, credentials and API key formats. This is one of its more powerful benefits. Anything that helps you understand your data is a major plus.

    Amazon’s new AWS security service supports 20 alert categories designed to provide early warning on security and compliance use cases, such as high-risk data events, API keys and credentials being stored within source code, unencrypted backups containing credentials and early stages of an attack, including behaviors indicating lateral movement, persistence mechanisms, back-door accounts and enumeration of role privileges.

    Whether Macie’s pricing makes sense for your company will depend quite a bit on the type of data you’re using in AWS. The pricing also involves the data analysis so it starts out higher as Macie analyzes your data store. On the other hand, if you are continuously adding significant amounts of new data, it may continue to get more and more expensive. Check out the detailed pricing information for some insight. Amazon lets AWS customers try before they buy Macie with this test drive. You may also find its FAQ and documentation useful in assessing the tool as well as more details about AWS security.

    Analysis

    Any enterprise application that mentions the terms artificial intelligence or machine learning in its marketing materials sets off alarm bells these days. It’s not uncommon to find that such laims are more hype than reality. Enterprise buyers, beware. But Macie’s ability to classify data in risk terms is well within the state-of-the-art of machine learning today. There are no apparent flights of fancy or flowery marketing language involved. Amazon isn’t promising unrealistic things from its new AWS security service. In fact, Macie looks promising for the many enterprises that are using AWS.

    — Scot Finnie

  • DevOps and Security is Like Smoking Meat

    DevOps and Security is Like Smoking Meat

    It isn’t everyone who thinks, “Doesn’t Ubuntu remind you of wild boar?” Or labors over his pit of slow-roasted pork shoulder while contemplating containers. Or dwells on e2e testing while mesquite smoke permeates spareribs.

    But, Apollo Clark (@apolloclark) does. Apollo is a foodie of smoked meats (is that a meatie or smokie?), working to master the craft: understanding different cuts, what each type of wood adds, and the subtleties of sauces. But, alas, it is a hobby; security and DevOps are his career.

    Being passionate about both, he naturally sees parallels between the two, so Apollo presented at the 2016 All Day DevOps conference with a session titled, “What Smoking Meat Taught Me About DevOps and Security.”

    Understandably, you are asking yourself, “What does smoking meat have to do with DevOps and security?” Apollo notes both have tremendous complexity and nuances, there are multiple ways of getting the job done, lots of ways to mess it up, a couple of ways of doing it right, and you are always learning.

    apollo 1.png

    For both, there are many tools and processes to get the job done. For smoking, your wood is a critical component, along with time. Let’s look at some parallels:

    • Oak = unit testing
    • Maple = coverage
    • Apple = dynamic analysis
    • Peach = static analysis
    • Mesquite = e2e testing. People love it, but it is difficult to handle
    • Wine barrel = browser support. This is when you are doing it really well
    • Bourbon barrel = device support. Pretty complicated
    • Smoking time = testing. You can test or smoke for five minutes or five hours, but there is a sweet spot. You can oversmoke meats and you can overtest.

    Getting hungry?

    apollo2.png

    Meat is critical to a meal of smoked meat, but so are many other components. Likewise, software applications take a suite of other tools and components to deliver the full package. Get your taste buds ready, because Apollo likens all of the goodness that goes with smoked meats to tools you use to keep applications running:

    • Sauces = auto-scaling. They both can get pretty complicated. Always a little different, but you have to make it work for you.
    • Bread = monitoring, which is the bread and butter of infrastructure. Make sure you have it up and down your stack.
    • Salad = system logs. Not the sexiest things, but you can rely on them.
    • Fruit = custom application logs. Takes a lot of time to pair them, but takes a really good thing and makes them better.
    • Beer = firewall. You should always have both.
    • Wine = Intrusion detection systems. These are your fine wines.
    • Whiskey = IR training. It takes time and there are so many ways of doing it. When things break, we have procedures on how to deal with them.

    When smoking meats and in DevOps and security, Apollo asks and answers, “Do we have to do everything? No, but the more we do, the better it will taste.

    “Does it cost money and take time? Yes, but you can do great things even without money and time. You can use cheap meats and you can use open source. Start simple, build up complexity, and always be learning.” Constantly ask yourself, “Am I better today than I was yesterday.” If not, be better.

    You can watch Apollo’s entire talk online here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free-of-charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks