devopsy.kinsta.cloud

Category: DevSecOps

  • State of the Software Supply Chain: Secure Coding Takes Spotlight

    State of the Software Supply Chain: Secure Coding Takes Spotlight

    After almost a year of research that involved studying 36,000 open source software projects, 12,000 enterprise development teams and 3.7 million open source releases, we at Sonatype are excited to share the “2019 State of the Software Supply Chain” report.

    This year, we worked with research partners Gene Kim, founder of IT Revolution, and Dr. Stephen Magill, principal scientist at Galois and CEO of Muse, to examine and empirically document objectively for the first time the attributes of exemplary development practices, especially in relation to secure coding practices. But, as in years past, we’ve also analyzed the rapidly expanding supply and continued exponential growth in demand for open source components.

    Not All Open Source Projects Are Created Equal

    For the past four years, we’ve studied the ins and outs of the software supply chain—what it’s comprised of; how vulnerabilities are getting in and how often; the growing regulations; and, most recently, a new trend in which adversaries are purposely attacking the supply chain with malicious components.

    For our fifth anniversary of the report, we wanted to look deeper. We wanted to understand exactly how enterprise development teams—and potentially even more importantly, how OSS projects—were thinking about and addressing the software supply chain security issues. We wanted to understand and identify the very best practices so we could share them with others.

    As a result of our research, we identified five common behavior patterns across 36,000 open source development teams. This includes identifying attributes of Large Exemplars and Small Exemplars who rest within the top 3%, or 1,229, OSS project development behaviors.

    To arrive at this list, we examined a large number of variables, including:

    • Do differences exist in how effectively OSS projects update their dependencies and fix vulnerabilities?
    • Are there exemplary teams that do this better than others?
    • Are components from exemplary teams more widely used than “non-exemplary” components?
    • What factors correlate with exemplary components?
    • What advice can be offered to producers of OSS components and the developers that consume them?

    The answers were quite striking—and the resulting data even more illuminating. While the report identifies Small Exemplars and Large Exemplars, we’ve also identified three additional groups of OSS projects: Laggards, Features First and Cautious.

    Secure coding: 2019 State of the Software Supply Chain

    Exemplary Commercial DevSecOps Practices Create Superior Software

    There are clear, competitive advantages for teams with exemplary DevSecOps practices.

    We’ve known for years that innovation is critical, speed is king and open source is at center stage. This research further underscores these accelerating trends throughout the software supply chain. It also shows that taming the supply chain is possible. By making better supplier choices, component selection and using automation, dev teams are seeing impressive rewards. In fact, for those development teams actively managing their software supply chains, the use of known vulnerable component releases was reduced by 55%.

    The report details 11 other behaviors and attributes of leading enterprise development teams, including their frequency of software releases, their use of repository managers and their reliance on a software bill of materials.

    Gene and Stephen helped shed new light on exemplary development and DevOps practices that I believe will help developers around the world better understand what secure coding means and how to start addressing it.

    — Derek E. Weeks

  • 6 Traits That Define DevSecOps

    6 Traits That Define DevSecOps

    How do we define DevSecOps? A combination of DevOps and security is readily apparent, but the philosophy goes much deeper. In a recent eBook, The State of DevSecOps, we asked industry experts to define what DevSecOps meant to them. Below, we’ve condensed their answers into five core attributes.

    Following these principles, CIOs or CTOs now have a DevSecOps doctrine applicable to nearly any software development and release environment.

    Security Automation

    DevSecOps emphasizes security objectives within the automation processes. Ben Newton, director of product marketing and evangelism at Sumo Logic, defines DevSecOps as first making security requirements and objectives a clear part of the continuous integration (CI) and continuous deployment (CD) cycle.

    Culture of Security

    DevSecOps establishes a team culture that embraces security concerns. As stated by Ben, a security team must provide “clear guardrails for developers as to what is fair game and what is not appropriate from a security perspective.” Building security expertise to integrate security into the entire DevOps lifecycle is critical.

    De-Siloing IT

    DevSecOps is about eroding boundaries. Just as DevOps has eroded the traditional separation between software engineering and IT operations teams, “DevSecOps further erases the walls between the DevOps team and IT Security,” said Tim Jarrett, senior director of product management at Veracode. “DevSecOps is about building a bridge between the security and DevOps teams,” echoed Dan Hubbard, chief product officer at Lacework.

    Security Shifts Left

    DevSecOps places security earlier on in the development process. IT security is traditionally viewed from a risk avoidance and compliance standpoint. Rather than viewing security as a gate, Tim noted that within DevSecOps, “security is better positioned to integrate earlier in the development cycle where they can actually make a difference.”

    Security Enables, Not Stalls

    DevSecOps supports, not stalls, agile development. DevSecOps doesn’t have to be sluggish. As Dan described, DevSecOps must “support the need for DevOps to move fast, but in a way where security is not ignored.” By embracing a security-as-code mindset and involving practices such as automated threat detection, agility is not sacrificed.

    — Bill Doerrfeld

  • DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    Wouldn’t it be helpful to know if other cloud users are seeing the same or similar attacks that you are? Security intelligence about cloud applications beyond just those you own and operate as an enterprise opens up a new dimension in attack visibility against even large sets of cloud apps.

    During AWS re:Inforce 2019, Sumo Logic announced it is extending its machine analytics and intelligence platform to include AWS GuardDuty. Dubbed Global Intelligence Service for Amazon GuardDuty, the new service is more than just a data aggregation and reporting play. The new service provides additional context around GuardDuty data by reporting attack information across multiple Sumo Logic customers using AWS GuardDuty. Essentially, it’s a “crowdsourcing” approach to reporting threat intelligence across the cloud.

    In this episode of DevOps Chat, David Andrejewski, senior engineering manager at Sumo Logic, joins us to talk about this new, more expansive threat intelligence service. More information about Global Intelligence Service for Amazon GuardDuty is available in the press release and website.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everybody, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by David Andrzejewski, Senior Engineering Manager at Sumo Logic, and our topic is a real meaty one—Global Intelligence Service for Amazon Guard Duty. David, welcome to DevOps Chat.

    David Andrzejewski: Thanks so much. Thanks for having me on.

    Ashley: Well, we really appreciate you being on the podcast today. Would you start by introducing yourself, just tell us a little bit about what yourself and what you do at Sumo Logic, and maybe just a brief overview of Sumo Logic the company?

    Andrzejewski: Yeah, fantastic. So, Sumo Logic, what we offer is a cloud-based machine data analytics platform, which is a bit of a mouthful, but what that specifically means is a cloud-based, multi-tenant service where you can send your logs and metrics and data to our service for helping you monitor, troubleshoot, and secure your applications, platform, environment, infrastructure for your own application or your IT infrastructure.

    So, we offer this as a kinda cloud-based web app service. The idea here is, you’re sending us all of that data and we can kind of manage the scale, reliability, and analysis for you and kinda help you focus on running your business and kind of running your app and everything like that.

    Specifically at Sumo Logic, I manage the Advanced Analytics Team, and we’re focused in particular on ways that we can do especially kind of useful or interesting things to help customers get more out of their data. So, some of the features in the past we’ve worked on are log reduce, which kind of applies clustering techniques to your logs to kind of give you a more comprehensible snapshot as well as outlier detection and things like this. But our current focus right now is this kind of Global Intelligence Service that we’re really excited to be announcing at AWS Reinforce.

    Ashley: Great. Well, we are a DevOps and also a security podcast—talk a little bit about how Sumo Logic fits into the DevOpsSec world.

    Andrzejewski: Yep, absolutely. So, ultimately, in any of these situations, you really need some kind of—you need the ground truth actual data to really kind of know what’s happening in your environment, both from what kinds of experience are your customers getting, how is the, kind of the health of your machines or what resources are available, what is the performance of various services, you know, events are being kind of logged and audited and then you’re kind of pulling data together from all up and down the stack into one place.

    And that’s kind of where we come in as sort of one kind of one-stop shop for sending all of these very kind of heterogeneous logs into one service such that the teams that are responsible for up time from kind of a DevOps SRE perspective and security from all sorts of aspects of that, which increasingly is, like you said, kind of this DevSecOps. The developers themselves are often increasingly deeply involved in all of that, where they can kind of pull together the data from their own kind of custom application logs, the infrastructure, the actual machines, the operating system, the firewall, the databases, the third party services and kind of have it all in one place so that when you can sort of help detect when things do go wrong and then kind of identify, dig in, troubleshoot what’s going wrong and then once you fix it, you know, verify that it actually is corrected.

    Ashley: Mm-hmm.

    Andrzejewski: So, you would interact with the service by sort of operating queries against your data, creating dashboards and visualizations and using these dashboards or potentially setting up alerts to notify members of your team that some condition has been triggered that requires immediate attention or action to generate sort of scheduled kind of reports on these kinda things and in general, kinda analyze and interact with the data, the raw data being kind of sent out by your software, your machines and everything like that to really understand what’s going on in your app.

    Ashley: And are you oftentimes the system in the SOC, or do you connect into a different monitoring system, alerting system in the SOC?

    Andrzejewski: So, this is kind of a—as far as the SOC aspect, some customers are kind of using it for tracking these different kind of logging events, others are sort of, we have a lot of kind of integrations with other services to kind of consume data kind of emitted by those services. So, for example, AWS Guard Duty, you know, alerts like that.

    So, it all kinda depends on, there’s sort of a wide variety of ways that customers have kinda made use of Sumo Logic. So, yeah, in some cases, I think that that’s a reasonable use case that the [Cross talk]—

    Ashley: It’s probably, I imagine, where they’re starting from if they have systems all ready for you to integrate in, or maybe you become the main single pane of glass, if you will.

    Andrzejewski: Yeah, so, in the security use case, I think—again, it depends on kind of which sort of person within the organization might be most interested in that. Developers often, you know, given that this is a place, a single sort of solution that you can collect the logs for both these kind of monitoring SRE troubleshooting as well as some of the security use cases.

    Ashley: Mm-hmm.

    Andrzejewski: That ends up being kind of an appealing property that you can kind of have one service to collect the data, analyze the data for various use cases, right?

    Ashley: Okay, great. Well, this is the week of AWS Reinforce, and I feel like we’ve kind of laid out enough teasers about your announcement that you’re making this week. [Laughter] Tell us about Global Intelligence Service for Amazon Guard Duty.

    Andrzejewski: Yeah, yeah, we’re really excited about this. So, the basic idea here is that we’re going to add some additional context around the Guard Duty alerts where we can essentially take your alerts and kind of recontextualize them in terms of how frequently we’re kind of seeing them or they’re being sent or observed across others.

    So, if something is a very kind of rare threat that very few other organizations are kind of getting, seeing in their environment, then that might be something that you would want to prioritize more highly, right, if you are—you know, there’s going to be some, in any kind of alerting system like Guard Duty or others, there’s often going to be a very kind of high just baseline of sort of very generic, general threats that everybody kind of sees at some base rate all the time, and this is kind of one way that you can sort of kind of do some noise reduction on those and really kind of prioritize and focus on the ones that are a little bit more idiosyncratic or unique to your environment and more, perhaps more interesting and more relevant for kind of immediate investigation and triage.

    And this is kind of being exposed to the customers via an app, which is kind of, in the Sumo Logic scenario, it’s kind of some pre-defined analyses and dashboards against your Guard Duty data. So, your customer would sort of consume this service by installing the new Guard Duty with Global Intelligence Services app, and they would immediately get access to these new visualizations, analyses, and dashboards that kind of place their own Guard Duty alerts in this modified context, this more—you know, bringing in a little bit broader information about how often these are being seen in other environments, what are the general most common threats, threat purposes, various threat types seen across sort of the general customer population at Sumo Logic.

    And this will sort of kind of serve these multiple purposes for the user—on one hand, helping you kind of prioritize rare events, on the other hand, kind of giving you sort of this bird’s eye view survey of what’s generally out there, right? And that can help potentially in prioritizing or allocating efforts at improving your own security posture or efforts in, for example, you see that a particular kind of threat is especially prevalent, you know, elsewhere, that might be something that you say, “Okay, well, what do we have to be doing to make sure that we’re, our bases are covered with respect to that ourselves,” right?

    So, ultimately, we want to kind of show you your AWS Guard Duty threat data, but in this kind of enhanced context that’s hopefully going to be more meaningful and more relevant to you and help you make better decisions and kind of run your business more securely.

    Ashley: Okay, so, the benchmarking aspect of this, is that something that happens in real time? You know, we’re looking at the console, we’re getting alerted to say, “This attack is happening, and by the way, it’s happening on 20 percent of the other AWS customers” or however your present it, or is it more a retrospective looking at past data of what’s occurred over the last month, last quarter, last year? Or is it both?

    Andrzejewski: Yeah, so, this is something that we’re kind of, in some sense, as we are having conversations with customers, seeing what’s going to be most valuable for their use cases. Right now, the real time—is it real time, like, up to the second? You know, is that really something that’s going to be valuable, or is that going to be kind of too noisy of a signal?

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, it’s derived from sort of recent history in some sense, and yet, potentially, that’s an interesting question of whether more very long term stuff, like, month over month is going to be useful for people, but you know, is it—right now, we’re not kind of focused on the use case of, you know, up to kind of real time real time.

    Ashley: Mm-hmm.

    Andrzejewski: Really, your data will still be real time, real time, but the question of whether that’s—you know, does the context need to evolve that quickly, or is that just going to kind of introduce more noise?

    Ashley: Right.

    Andrzejewski: Part of the advantage of kind of using a little bit of a recent historical window is looking at—you know, it gives you a little bit broader pool of data to kind of contextualize your real time activity against, right? So, again, it’s all about sort of your data and kind of seeing how—you know, how it kind of looks in context of this broader view and evolving the broader view in real time. It’s an interesting thought.

    Ashley: Well, that makes sense, too, because you may be having a false positive or something. Not everything that is being highlighted by Guard Duty might be as relevant as other things, so if you have a chance to filter some of that information out to say, “This is what’s relevant” versus, if everything’s real time, you could introduce some noise, maybe some things that aren’t as helpful, too.

    Andrzejewski: Yep. Yeah, exactly. So, it’s—that’s definitely a potential tradeoff, there.

    Ashley: So, what would you learn—because now, there must be some kind of an opt-in where you’re looking at events that are happening across different customers, AWS users—what would you learn by knowing that a whole other population of people are seeing this same kind of attack versus if you were only looking at your data, if you had known that you would do something differently?

    What would be a scenario like that where this would be super helpful?

    Andrzejewski: Right, so, the—you know, one kind of particular case sort of going the other way of a rare event might be that, you know, again, so, some of these threats are going to be very kind of common, and it ends up that that’s not something quite as potentially actionable or something that you need to jump on right away, but there’s still kind of part of your Guard Duty feed and they’re going to kind of potentially be a little overwhelming when you’re looking at everything. Whereas this more kind of like rare threat type, this—by kind of knowing, “Okay, this is a little bit out of the ordinary in that lots of customers are not seeing this,” that kinda helps it pop to the top of your queue and maybe you are going to allocate your very limited time and attention to focus on that.

    It might be a little more challenging to prioritize or see that kind of rare event pop, because you don’t necessarily know that it’s rare, you just sort of see it amongst all of the other kind of more common alerts and more common threats.

    Ashley: Right. This is a rare event, something that’s unusual, you should take a look at this versus something that’s happening normally across multiple AWS accounts.

    Andrzejewski: Exactly. That’s exactly right. And so, that potentially becomes a valuable tool to kind of—like I said, ultimately, teams everywhere are ultimately struggling with the scarce resource of your time and attention.

    Ashley: Mm-hmm.

    Andrzejewski: And anything that can kind of bring in some additional context information to help you allocate that time and attention more efficiently, more effectively is potentially, hopefully going to give some good value for our customers.

    Ashley: Well, many resources are precious resources, and certainly security folks are definitely in that precious category. So, being able to assign them to something you know is something we need to look at versus kinda chasing things that we really don’t need to be paying attention to would be super valuable.

    Andrzejewski: Absolutely.

    Ashley: So, obviously, Sumo Logic does a lot of other things in your products. You have operational analytics, business analytics, those kinds of things. Does this Global Intelligence Service tie into those in some way, to give you some additional broader insights, or this focused really—just really heavily on the security aspect of what’s happening in Guard Duty?

    Andrzejewski: No, absolutely—that’s a really good point. So, right now, kind of, very sort of aligned with Global Intelligence is some of the stuff that we’ve been doing a few years now around the modern app report and similar where kind of giving these sort of horizontal views of technology choice trends and various kind of software choices, infrastructure, cloud provider choices, kind of adoption of various tools and technologies across the industry, and that definitely kind of extends into the, kind of the DevOps SRE space. And again, hopefully the idea there is that these tools kinda give you this sort of broader context about actual hard data where various—you know, where the market in general is on their journey to cloud adoption or their migration to Docker or Kubernetes or other kind of related technologies.

    Ashley: Mm-hmm.

    Andrzejewski: So, that’s one place where there’s already something in place at Sumo Logic that’s kind of bringing that broader sort of horizontal context to bear to kind of help teams kinda make more effective, more informed decisions and, again, prioritize and allocate their attention and efforts in kind of using that extra information to kind of know, actually, from the hard data where others are actually at.

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, this particular announcement at AWS Reinforce is focused on Global Intelligence Services for AWS Guard Duty in particular which, as you said, is absolutely a very kind of security focused use case.

    Ashley: Mm-hmm.

    Andrzejewski: But in general, the general sort of Global Intelligence Services, you know, kind of platform and approach is something that we’re also actively thinking about how can we help in the operational analytics use cases? Where are there places where that broader context is going to help our customers make better decisions or solve their problems more quickly?

    So, right now, we have this Guard Duty announcement, definitely focused on security, but in general, we see Global Intelligence Services as a very powerful kind of horizontal enabler across the SRE DevOps kind of side of the house as well.

    Ashley: Mm-hmm. Yeah, it seems like an area that would be ripe for machine learning—yeah, the statistical analysis that you could do across multiple areas of the analytics that you’re doing. You know, that’s what data’s all about, right? What insights and learnings can you get from that that brings additional value benefit to the business?

    Andrzejewski: Definitely, yep.

    Ashley: Well, good. Is this product available now? Is it coming out some time down the road? How soon can we get our hands on this?

    Andrzejewski: So, as of the kind of announcement, it should be available to Sumo Logic customers at the enterprise level, and again, it would be a matter of installing the app and kind of start—obviously, in this case, you would need Guard Duty as well. I can provide some links to go out with this, if that’s helpful—

    Ashley: Sure.

    Andrzejewski: – that would have kind of links to the specific resources that would be involved in getting started and getting set up with this, but yeah.

    Ashley: Okay, great. It sounds like a pretty easy thing to do to get started. If you’re already running Sumo Logic, installing the app is not a heavy lift, it’s pretty straightforward.

    Andrzejewski: Absolutely. And the other aspect, of course, having Guard Duty in place as well. Which, again, is—in the links I’ll send, should be, is a pretty painless process.

    Ashley: Excellent! I also want to mention, too, that Sumo Logic is located in Booth 714 at the Reinforce conference. So, definitely recommend folks stop by and maybe see a demo of this, get to talk with folks about the new announcement.

    Well, our podcasts have no problem flying by quickly, because we talked about great things and I appreciate you doing that with us. David, I’d like to thank you, David Andrzejewski, Senior Engineering Manager at Sumo Logic, for joining us.

    Andrzejewski: Well, thank you so much for having me. It’s been a really great conversation—super, super interesting to talk about.

    Ashley: Great. It’s good stuff, and I wish you and Sumo Logic the best at the show this week.

    I’d like to also thank you—you, our listeners—for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Portable Security Policies: A DevSecOps Primer

    Portable Security Policies: A DevSecOps Primer

    Protecting critical data and applications is a challenge under any circumstances, but it’s especially daunting when resources reside in the cloud. Most organizations today operate a significant portion of their workloads in the cloud, which adds to the complexity of the security problem—a security team can’t fully control cloud environments but is responsible for securing workloads and applications running there.

    Cybercriminals are exploiting the situation. They’re becoming more aggressive and ingenious in their efforts, taking advantage of the fact that there is confusion about who is responsible for which aspects of security under the Shared Responsibility Model. Adding to the chaos is the differentiation between cloud providers’ security offerings and capabilities. Quite simply, in most cases, cloud providers are responsible for the security of the cloud and consumers are responsible for security in the cloud, meaning that security and networking teams still need to ensure their organizations’ workloads and applications are free from malware or other tampering.

    To accomplish this, security and networking teams can’t rely solely on firewalls, threat detection and vulnerability patching to secure vital digital assets. Security tools developed for traditional data centers are not effective at securing workloads in the cloud due to the cloud’s dynamic nature. Security and networking teams must rethink their approach.

    Unfortunately, many organizations are still relying on old and ineffective strategies—further hardening the perimeter, investing in additional threat detection and adding new tools and controls that focus on identification rather than prevention. This security approach has its place, but it does nothing to prevent malicious actors from moving laterally across the network once they achieve a foothold, which leaves cloud-hosted apps and workloads extremely vulnerable.

    Instead, security teams need to enable zero trust in cloud environments, which treats all internal communications as untrusted by default. With zero trust, only authorized applications and services are allowed to send and receive communications, and only in specific ways governed by the principle of least privilege.

    The Second Layer

    Traditional tools aren’t effective in enabling zero trust in the cloud because security and ops teams have a very limited ability to manage all layers of the cloud’s open systems interconnection (OSI) model. Specifically, the lack of Layer 2 controls in infrastructure-as-a-service (IaaS) environments makes tools developed for discrete networks all but useless for locking down ports and controlling or scrutinizing IP addresses.

    Even if an organization manages to implement these tools in the cloud, it cannot provide the level of granularity required to stop malicious lateral movement. For example, when on-premises tools are repurposed for cloud environments, they usually rely on subnets to define the boundaries of communication. Because cloud subnets are designed to handle elastic workloads, they need to be far larger than those in on-premises environments. As a result, cloud workloads are more exposed than is necessary.

    Securely migrating workloads and applications to a cloud environment is a huge and cumbersome job when relying on traditional tooling. The best way to make workloads portable and secure is to decouple workload protection from the underlying infrastructure. In this way, organizations can be certain that any policies applied on-premises can migrate to the untrusted environment of the cloud, without the complexity of mapping changing network addresses, writing policy exceptions or losing fine-grained control during the process.

    Decoupling workload protection from the network requires abandoning a network address-based approach in favor of one based on identity. By using the immutable properties of workloads, security teams can create cryptographic identities for applications and services, which then can be used to determine what is allowed to send and receive communications. Not only does this model provide stronger security, but it also works regardless of where applications are located, because these identities are unaffected when network elements change. What’s more, they can be constructed to tolerate upgrades. By building identity-based policies, security teams can create microperimeters around applications that follow workloads wherever they go, and the policies verify communication across boundaries every time an application attempts to communicate.

    Implementing network-agnostic policies doesn’t just harden security. Software developers benefit as well. Without the roadblock of translating application-speak to network-speak, developers can build software and applications in any environment favorable to their workflow while defining policies to protect their work. Once the software is built, they can securely deploy the finished product to the production environment—even if it is hosted by a third party.

    No organization should have to compromise security to benefit from the efficiencies offered by the cloud and ephemeral auto-scaling containers. Building identity-based policies that enable zero trust and are independent of the underlying network ensures that companies never have to consider making that trade-off.

    — Tom Hickman

  • Data: the New Currency That Accelerates Business

    Data: the New Currency That Accelerates Business

    The amount of data created every day is staggering: 2.5 quintillion (that’s 18 zeros) bytes, to be exact. And that number is growing exponentially, thanks to mass deployments of internet of things (IoT) networks and devices. Cisco Systems estimates that by the end of 2019, IoT will generate more than 500 zettabytes of data per year. In the past two years alone, 90% of all the world’s collected data was generated.

    If it’s hard to imagine that such staggering volumes of data can be generated so quickly, just look around. There are IoT devices in our homes, vehicles, business offices, hospitals, shopping malls and parking lots and along highways, each generating and collecting data. Myriad sensors, cameras and listening devices collect human-generated data. Such devices are pervasive, and the number of data-capturing sources are making the information collected about us ubiquitous.

    Value vs. Privacy

    One might say we are human data machines. So, is data the measure of a person? While this is a relatively new phenomena, data has always been available about our activities, likes, dislikes, motivations and more—it just hasn’t been collected, aggregated and analyzed in the way it is today. It’s like we’ve discovered a vast vein of data gold that has always been hidden beneath the surface.

    IoT is becoming big business. Yet, the real value of IoT is in the data, as meaningful insights are derived and then leveraged for a business advantage. With artificial intelligence, automation and business intelligence, the more data collected, the smarter the applications become and companies gain more insights, increasing the value of data. However, there are legitimate security and privacy concerns as organizations collect our information, most often without our knowledge.

    Data is becoming the currency that drives our economies and a motivation manipulator that impacts our societies, with both good and bad results. If data represents currency, as it helps companies achieve greater revenue and efficiencies, how can consumers be in control of their own data and share in its rewards? How can they make sure their information is not put in the hands of those who want to use it for ill-gotten gains at their expense? These, and other important questions, need answers and solutions that protect consumers, as we look for innovative ways to put a boundary around our personal digital vaults before our data enters the marketplace.

    As consumers, do we care that this data is being collected? Is the benefit of receiving free services worth the price of our information? What should consumers do to make sure their data isn’t used in ways they don’t agree to? Perhaps consumers should expect companies to include them in their revenue-sharing. If they want to share in their data monetization, those collecting the data should ensure the data is protected and private, with full data-use transparency.

    Data Value Directly Related to Data Integrity

    When malicious actors gain access to data, not only does it put us at risk, but it also can lower the value of data. Consider this scenario of a hacker gaining access to data from the insurance company’s network-connected device in your car: The data on that device could have lowered your premium, but the hacker changed the information to show much higher speeds and extreme braking, then threatened you to pay a ransom or risk the hacker sending the altered data to the insurance company. In this case, because the IoT device was hacked, the financial impact of your data changed from a financial advantage to a financial disadvantage. Remember, data value is directly related to its integrity.

    There are two important things we must consider regarding IoT data. The first is to consider how the data is being secured. Is it encrypted while in transit? Are encryption and authentication deployed to prevent unauthorized users from accessing data when it is stored at rest? The second consideration is around privacy. How is the data being used and shared? Is sensitive data that we want protected being consumed and shared? Are device manufacturers providing consumers with transparency regarding whether and how their data is being used? Without establishing firm foundations in security, privacy and transparency, the protection and the monetization of our data will continue to be out of our control.

    — Mike Nelson

  • DevOps Security Champion: Who, What and Why?

    DevOps Security Champion: Who, What and Why?

    In general, DevOps is a process and culture of organizations to get applications out the door faster and with higher quality. To do so, security champions are essential. In DevOps, security champions work as a backup mechanism in various projects and take multiple leadership roles.

    Security champions make effective decisions and take projects forward while strengthening the best security practices. How do you enable security champions in DevOps? In this article, we will describe four practical ways of enabling them in DevOps. But first, we will discuss their role in more detail.

    Security Champions in DevOps

    Let’s suppose you are accountable for creating a mature security process across an organization. To fulfill this project, there are various teams working on different product and services, using multiple technologies and an active approach. However, some team approach security ad hoc security activities while others use existing security technologies and processes.

    After a few weeks of reading documents, learning about calendar releases and suggesting specific knowledge and best practices, you realize that your best efforts around security haven’t addressed myriad issues. You need help, but the central security team isn’t budgeted to help your team. This is where security champions come in.

    Security champions play a vital role in DevOps. They are dynamic members of a team who help in making decisions about the engagement of the security team.

    They act as a fundamental element of the security assurance process for the product and service, and are the main point of interaction within the entire team.

    By taking different leadership roles and decisions inside a smaller team, security champions form a shield of sorts for the team leaders. They give them the freedom needed to drive the project further while supporting and emphasizing the best security practices in the project.

    Enabling Security Champions in DevOps

    Here are four ways to build an efficient team of security champions.

    1. Identifying Teams

    The first and most important thing in building a competent team of security champions is to identify the team you are going to work with. In this phase, distribution of tasks occurs. It is important to note this step should be done before starting the project; otherwise, miscommunication and other problems could occur.

    It is essential to keep a record of the team so the other development departments also know who is reponsible for which of the various tasks.

    To implement this step, you need to talk with the decision-makers and technical managers, such as product owners and company heads to find out information such as the number of people working on different projects and how they can fit into the development teams already working on the project, what programming languages and various frameworks are being used and how they are being implemented.

    2. Role Distinction of Team

    It’s also important to define the role of each team member. Every team must have its security champion assigned to them and the security champions must know what they are supposed to do.

    The security champions should have well-defined goals and purpose, and the rest of the team should communicate with them to ensure best security practices are implemented. The security framework the project follows was selected during its planning phase. As such, the entire team must work with the security champions to ensure the security of the application.

    The security champion should also conduct security reviews regularly, especially at milestones during the project.

    It is important to note that protecting security best practices is not just the security champion. Rather, it is a collective effort of the entire project team.

    3. Select Champions

    Once you have identified the team and defined the roles, the next step is selecting the champions. To accomplish this step, you need approval from managers at all levels, from to-level to product owners and direct team managers. They can help you identify potential champions, choose eligible candidates and conduct interviews to judge their capabilities.

    Because this is the selection stage, you need to describe the role clearly to the selected candidate. You also may explain the strategy you plan to adopt as well as the advantages of becoming a security champion. These include:

    • The chance to attend various security conferences.
    • Being a part of the security meta-team.
    • Increased value in the marketplace.
    • Better product quality.
    • Personal development and the ability to look at things differently.

    4. Stay Connected and Communicate Clearly

    The security champions are required to communicate consistently with their team members and project leaders. They can use any of the various communication channels available to collaborate effectively:

    • Messaging apps
    • Email
    • VoIP apps
    • Mobile phone apps

    Security champions also need to combine as much of the technical data as possible to provide the team safe and secure access, thereby fostering a collective approach toward secure product development instead of keeping everyone in remote smaller groups who don’t exchange knowledge.

    Conclusion

    Security champions play a significant role in DevOps because they introduce a sense of responsibility of security within their department. Their participation starts small and increases gradually. Their presence benefits not only the company but also the application or service itself.

    There are different ways by which you can enable security champions in DevOps to add value to your project. By doing so, you are helping to create a culture of security awareness, which leads to secure applications and improved quality security features.

    — Zehra Ali

  • Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    How Red Hat’s Open Innovation Labs have helped accelerate Lockheed’s software development for the F-22 Raptor

    As the key government contractor charged with helping the U.S. Air Force keep its F-22 Raptor jets in fighting trim, Lockheed Martin Aeronautics increasingly values software delivery speed as much as engine speed. So much of the continued evolution of these fighter jets depends upon continual upgrades of the software code powering all of the physical systems built into them, from tip to tail.

    Until a year ago, these jets, which first rolled out of the manufacturing plant in the 1990s, were supported by the waterfall development methods of that same era. Lockheed executives and Air Force brass recognized that the F-22 needed a DevSecOps transformation, and fast.

    “When you have a world-renowned platform like the F-22 Raptor, adversaries are constantly looking for ways to counter it,” said Michael Cawood, vice president of F-16/F-22 product development at Lockheed Martin. “This means we must constantly add capabilities and improve the F-22. And we must do it faster than ever before. We needed to transform our own organization and how we did things.”

    To accelerate that process, Lockheed last year sent a small contingent of engineers through a residency program at the Red Hat Open Innovation Labs to fast-track the process of implementing an open source architecture onboard the F-22 while adopting agile development methodologies and DevSecOps practices. Since bringing back their learning to the organization, these engineers helped to catalyze a faster development process that has helped Lockheed introduce software features for the F-22 years ahead of schedule.

    How Open Innovation Labs Works

    Now in their third year of operations, the Open Innovation Labs were developed by Red Hat as immersive training grounds to help its enterprise customers figure out how to deliver better software, faster. A standard engagement has companies such as Lockheed pay for residency for anywhere between three to six developers and operations staff to get paired one to one with Red Hat employees—engineers, consultants and others—with deep knowledge in DevOps and agile development. They work with them in a time-boxed four- to 12-week engagement to build out application prototypes using DevSecOps practices along the way. The residents are also teamed with a designer and an engagement lead who doubles as an agile coach, typically working with the customer’s product owner for the prototype.

    Obviously, Red Hat has a vested interest in training these people in technology such as its OpenShift Container Platform, getting them up to speed on how to orchestrate and manage containers and microservices. But the labs approach is in a different league than the standard vendor training program. It more closely follows the DevOps dojo model that enterprises like Target and Capital One are running internally to scale up cultural and process transformations across their IT organizations. Like those dojos, the working model is to build real software through a guided learning process that helps participants get hands-on experience in how to change the way they deliver software.

    Red Hat runs the labs either out of a handful of dedicated spaces it runs around the world or within pop-up labs of the customer’s choosing. Besides Lockheed, other notable alumni include the likes of Volkswagen, UNICEF and Heritage Bank. According to a recent analysis by Forrester Consulting, participants in the Open Innovation Labs program are accelerating application development by more than 60%.

    Lockheed’s Accelerated DevSecOps Transformation

    In Lockheed’s engagement with the Open Innovation Labs, the organization sent out a cross-functional team of five developers, two operators and a product owner. They were tasked with building out a new application for the F-22 on OpenShift, using that process as a model for future development workflows. As a part of the process, Lockheed also worked with the labs to help it build out an internal dojo that could facilitate the scale-out of the knowledge gained by its small team across the entire F-22 development team. Six months after the initial residency, Lockheed managed to scale its OpenShift deployment and DevSecOps transformation across its entire 100-person team.

    “By working with the Red Hat Open Innovation Labs team, we changed everything—our toolchain, our process and, most importantly, our culture,” explained Cawood.

    As a result, the F-22 development organization has been able improve its ability to forecast for future sprints by 40%. More importantly, it has cut what was once an onerous five- to seven-year process of rolling out new software capabilities for the aircraft. Lockheed is on track to deliver new communications capabilities for the F-22 this summer a full three years ahead of schedule.

    — Ericka Chickowski

  • Security: Are You Doing DevOps Right?

    Security: Are You Doing DevOps Right?

    Phil Kernick, co-founder and CTO of cybersecurity specialist CQR Consulting, has no fundamental problem with DevOps, but asks, from a security perspective, “How many people do it right?”

    If DevOps is going to work and produce secure systems, then developers must take responsibility for security. It’s not something that can be treated as an additional process.

    But abstract responsibility isn’t sufficient. It’s rare for developers to have security tools in their kit and an understanding of their results, said Kernick.

    Learn From History

    As former systems administrator and past president of the Systems Administrators Guild of Australia (SAGE-AU, now the Information Technology Professionals Association), Kernick suggested that DevOps pretends that the discipline of systems administration does not exist and merely treats infrastructure as if it were a software library.

    Spinning up an instance is easy, but do you know that it is properly designed and maintained? This is a real concern, given the number of people working as developers without professional training, Kernick explained.

    Repeatable loops and short development cycles do make sense. But are you confident all the individual pieces being assembled were built properly?

    That raises questions about the software supply chain. Where did that Docker container actually come from? Is it well-maintained?

    The process needs to be managed, yet, people at some organizations are “just grabbing things from anywhere,” Kernick said.

    “It almost integrates the ‘not my problem’ attitude with development,” he noted.

    Developers tend to care about whether a component works from a functional perspective, but an untrustworthy piece of code will compile and run.

    Developers working in a DevOps environment need to understand the tools that help ensure code is secure, and they need to understand infrastructure, said Kernick.

    ‘Code Reuse is Bug Reuse’

    DevOps makes the old joke that “code reuse is bug reuse” even worse, said Kernick, citing the example of a piece of vulnerable code shared on the Stack Overflow site and reused more than 100,000 times in GitHub-resident projects.

    “I don’t want DevOps running in my bank,” he said. What he does want is well-engineered, secure, well-run, certified software.

    Sacrificing security might save some time and get a new product on the market sooner, which might be acceptable if there are no real risks to the user.

    It is easy to tell if a system is really important, as it involves tradable value, safety or privacy. Obvious areas include banking and health. Similarly, it is clear that a website that allows access without requiring any credentials is unimportant.

    But there’s a wide middle ground where it’s “really hard” to determine a system’s importance because it is so difficult to imagine how criminals might exploit it.

    For example, Kernick once bought a DVD cataloging app to help avoid duplicating items already in his very extensive collection. He thought this fell into the “unimportant” category. But—fortunately, as it turned out—he took the usual precaution of using a unique password for the associated service. Sometime later, he received a sextortion email that proffered that password as supposed proof that the criminal had gained control of his computer.

    Worryingly, when he told the developer what had happened, it did not accept that there was a problem. The company said the password quoted in the malicious email wasn’t his password for the service—proving in the process that it was storing passwords in plain text!—even though he explained he changed his password as soon as he received the message. Predictably, he uninstalled the app.

    Clearly, Kernick didn’t know what development methodologies that company used, but that’s not the point. The anecdote shows that a seemingly unimportant system can quickly become important to the user in situations outside the developer’s control. Consequently, security is always important.

    DevOps and Security

    He suggests that as long as an organization has the right security and governance processes in place, it won’t matter what development methodologies are used. So it can safely adopt DevOps or whatever else is most efficient in the circumstances.

    It is possible to use DevOps practices to achieve speed without sacrificing security, Kernick said. But to do that, organizations need to take advantage of advances in software development without throwing away hard-won security experience.

    — Stephen Withers

  • The Bug in Production: What You Don’t Know Can – and Will – Harm You

    The Bug in Production: What You Don’t Know Can – and Will – Harm You

    Despite the risk of unplanned downtime, many organizations that develop software and services push them live without adequately testing for bugs that will manifest against production traffic. This is a huge gamble: Those bugs could lead to errors that bring down the service altogether. Pushing live without sufficient testing can be detrimental to your business.

    The Problem of Going Live With Bugs in the Code

    Software downtime leads to loss of revenue and of reputation. In fact, Gartner analysts have estimated that the average cost of downtime is $5,600 a minute—that’s well over $300,000 an hour. To provide a real-life example of what this looks like, Microsoft Azure suffered a major outage in November 2018 caused by issues introduced as part of a code update, lasting for 14 hours and affecting customers throughout Europe and beyond. With migration from legacy systems to micro-environments in the cloud, outages and downtime pose a growing and serious problem.

    As companies switch to DevOps and CI/CD models to move faster and provide application updates sooner, software developers continually release new features and often push code updates as fast as they’re written. The classic six-month development timelines of dev, quality assurance (QA) and beta testing have been compressed to days and sometimes hours. Gone is the time when teams could beta test with customers for extended periods to flag real-time bugs.

    With current quality testing tools, developers don’t know how a new software version will perform in production—or whether it will even work in production. The Cloudbleed bug is an example of this problem—in February 2017, a simple coding error in a software upgrade from security vendor Cloudflare led to a serious vulnerability discovered by a Google researcher several months later.

    Flaws can lead to serious security issues later, in addition to having the immediate impacts mentioned above. Heartbleed, a vulnerability that arose in 2014 and stemmed from a programming mistake in the OpenSSL library, left large numbers of private keys and sensitive information exposed to the internet, enabling theft which otherwise would have been protected by SSL/TLS encryption.

    Standard QA Testing Isn’t Enough: Test With Production Traffic

    The way QA testing is typically done is no longer sufficient for today’s increasingly frequent and fast development cycles. Traditionally, DevOps teams haven’t been able to do side-by-side testing of the production version and an upgrade candidate.  The QA testing used by many organizations is a set of simulated test suites, which may not give comprehensive insight into the myriad ways in which customers may actually make use of the software. Just because upgraded code works under one set of testing parameters, doesn’t mean it will work in the unpredictable world of production usage.

    As in the case of the Cloudflare incident, the error went entirely unnoticed by end users for an extended period of time and there were no system errors logged as a result of the flaw. Just as QA testing isn’t sufficient, relying on system logs and users also has a limited scope for what can be detected.

    It is estimated that fixing flaws after a software release can be five times as expensive as fixing them during design—and it can lead to even costlier development delays. Enabling software teams to identify potential bugs and security concerns prior to release can alleviate those delays. Clearly, testing with production traffic earlier in the code development process can save time, money and pain. Software and DevOps teams need a way to test quickly and accurately how new releases will perform with real (not simulated) customer traffic and while maintaining the highest standards.

    By evaluating release versions side by side, teams can quickly locate any differences or defects. In addition, they can gain real insight on network performance while also verifying the stability of upgrades and patches in a working environment. Doing this efficiently will significantly reduce the likelihood of releasing software that later needs to be rolled back. Rollbacks are expensive, as we saw in the case of the Microsoft Azure incident.

    Some organizations stage rollouts, which requires running multiple software versions in production. The software teams put a small percentage of users on the new version, while most users run the status quo. Unfortunately, this approach to testing with production traffic is cumbersome to manage and costly, and still vulnerable to rollbacks. The other problem with these kinds of rolling deployments is that while failures can be caught early in the process, they are—by design—only caught after they’ve affected end users.

    This brings more questions, including: How do you know whether the new software is causing the failures? and, How many failures does the business allow before recalling or rolling back the software, since the business does not observe side-by-side results from the same customer? This disrupts the end user experience, which ultimately affects business operations and company reputation. And staging may not provide a sufficient sample to gauge the efficacy of the new release versus the entire population of customers.

    Cost is still an issue as well. If you stage with 10% of customers on the new version and a failure costs more than $300,000 an hour, then a failure affecting 10% of users could potentially still cost more than $30,000 per hour. The impact is reduced, of course, but it’s still significant—not counting the uncertainty of when to rollback.

    Looking Ahead

    Standard QA testing is no longer enough. To reduce the risk injected into the software development life cycle by today’s rapid iterations, DevOps teams can test in production and evaluate release versions side-by-side. This will help prevent costly rollbacks or staging while still releasing a quality, secure product. The old way of doing things is not sufficient, but fortunately, there is a better way.

    — Frank Huerta

  • Motorola Solutions: Driving a Thriving Security Culture

    Motorola Solutions: Driving a Thriving Security Culture

    It’s crunch time in the cybersecurity industry. For too long, many companies have remained unmoved by the increasing threat of cyberattacks, despite increased digitization of their products and services. Customer data is the new gold, and some organizations are leaving the door to their vault wide open.

    In saying that, secure development is complex and not without its challenges, especially at scale. In my experience, it is an uphill battle to win over developers on secure coding and best practices. In the mind of a busy programmer working to achieve strict delivery deadlines, security is not a priority over feature development and function—it is instead seen as a tedious task that interrupts their creative flow. However, if we are going to ready ourselves in the battle against those who seek to do harm, this culture needs to change.

    Marilyn Barrios is the senior cybersecurity training manager at Motorola Solutions, running the security training program for its team of more than 6,000 developers across the globe. Her goal is to ensure that those on the front lines of the company’s extensive software development are equipped with the knowledge, tools and ongoing training required to combat the growing global cybersecurity threat.

    To accomplish this, Barrios created an impressive internal security culture, one that thrived not only from a core skills perspective, but also in understanding its paramount importance in overall software quality. Her people-first, positive approach engaged the development team, created excitement about security and morphed into something far more powerful than a simple compliance exercise.

    “Ensuring that our products are secure is our highest priority. That’s why we’re working to create a culture of security-first thinking across the company—so people not only understand cybersecurity and why it is vital to maintaining a high standard of software quality, but are also excited to learn more,” she said.

    With such a large development team covering multiple facets of the business, insight into each individual’s security knowledge and current skill level could be elusive and difficult to collate. Barrios sought to streamline this process, working toward a holistic solution that would deliver key metrics and relevant training in the languages and frameworks that were actively being used in the business while remaining engaging enough to be revisited—even for more senior engineers.

    Marilyn and her team worked to implement an immersive, engaging training experience for their developers. Starting with a boot camp run by security superstar Jim Manico, the developers learned offensive coding techniques before playing in tournaments to test their defensive skills against the attacks they had just seen in action. This setup proved effective and eye-opening for the participants.

    “In really diving deep into how cyberattacks can be executed, the team saw how easy it was to do a lot of damage at the application level,” Barrios noted. “By then practicing how they can defend against these attacks, developers’ eyes were opened to how they can help if they keep security a priority in their work. They enjoyed the experience and it was also beneficial for them.”

    I was proud to see how well she and her team at Motorola Solutions executed a comprehensive, engaging and fun security training program that not only lifted security awareness IQ overall, but also helped to identify a new group of champions to keep the critical message of cybersecurity best practices thriving long-term within the organization.

    It was also interesting to learn that the eventual winner of the tournament did not start the program as the most experienced and security-aware developer. The boot camp was instrumental in rapidly upskilling the individual, and the gamified aspect of the training ensured a high level of engagement and information retention.

    “Our eventual tournament winner was so excited with the boot camp, and he was so engaged with the training tool. He practiced so much in a two-month period, improving so significantly, that he ended up winning the tournament,” Barrios said. “From there, he recruited even more champions, piqued their interest in security and helped them along to become advocates in their respective groups.”

    Barrios’ broader goal of creating a strong buzz that encourages an organic security culture to grow within the company is certainly on track.

    Gamified training, team events driven by tournament initiatives and the incentive to keep engaging with AppSec have resulted in something very positive: Developers not only are working to have a better understanding of security, but also actively seek to uphold company best practice initiatives day to day.

    Motorola Solutions saw measurable improvement when using tools and training compatible with the creative, problem-solving mindset of many developers, enjoying a training participation rate of more than 90%, with security accuracy increasing 24% across the global tournament that followed. Its internal security champion program has also seen immense support, growing by more than 1000% in the last 18 months. The company currently boasts 173 champions across its various product lines and will double that again over the next year. It has set a goal of at least one champion per scrum team—an initiative that holds incredible value in continuing momentum and spreading positive security influence across the organization.

    Driving a positive security culture takes time, planning and dedication, but alongside the right tools and training, Barrios’ advice is a sound reminder that clear goals and communication are powerful in achieving widespread support and change: “Always tie objectives to the ‘why.’ You should know why you’re trying to meet a goal or influence change; don’t just give a direction with no context.

    “For us, it’s easy: we make it personal. Motorola Solutions is responsible for delivering key communications over mission-critical infrastructure and devices for public safety and commercial enterprises. First responders, citizens and front-line workers alike are relying on this technology to be as secure as possible, so we emphasize the importance of learning best practices,” she said.

    With every other day seemingly bringing bad news about the latest large-scale data breach, it is refreshing to see an organization with a highly successful security program—one that can only get stronger as its developers continue to train and become the security superheroes we need to protect our digital world.

    — Pieter Danhieux