devopsy.kinsta.cloud

Tag: Cybersecurity

  • How Work-From-Anywhere Impacts DevOps

    How Work-From-Anywhere Impacts DevOps

    Brian Lavallée from Ciena talks with Mike Vizard about how the work-from-anywhere movement has impacted DevOps, networking and security. The video is below, followed by a transcript of the conversation.

    Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Brian Lavallée who is senior director for solutions marketing at Ciena. Brian, welcome to the show.

    Brian Lavallée: Thanks. Nice to be here.

    Mike Vizard: You guys just put out this study talking about what’s happening on the technology impact from working from home. A lot of folks are accessing cloud resources. They have home networks that may or may not be up to the task. Are we looking at some sort of networking crisis coming up as we move to working from anywhere? Do people understand that bandwidth is going to be an issue?

    Brian Lavallée: I wouldn’t say it’s a crisis, but it is a work in progress. Just over the last year, year and a half, the global pandemic, our homes have turned into the new branch office, the new classroom. People are learning, playing, and working from home, and it’s put additional stress on the network. One of the main challenges is speeds, because now you have two, three, four people accessing the same broadband connection from home at the same time, and then you have the whole security aspect, where if your home is the new branch office, very often you need additional security to do work, not only with your head office, your colleagues, but also with your cloud applications.

    Mike Vizard: I have found myself trying to fight for bandwidth with an 11-year-old, so I know what the issues are and what the problems can be. Do you think companies, as we go forward, are going to turn around and say to their employees, “Here is the router we want you to use”? Are they going to give them that router, or the access point at home? How far will they go to make all this happen and maybe provide that additional layer of security?

    Brian Lavallée: Yeah, I think, for sure, adding additional security, even availability, a more resilient connection is necessary going forward. Companies or enterprises are going to implement this differently. Some may do a lot of their security capabilities in the cloud. This allows you to have a centralized location to do all your security, you know, talking about SASE, _____ connectivity, and because it’s centralized, it’s easier to implement and control, rather than having specialized devices or specialized software sitting on everybody’s laptop. If you’re a large enterprise, you can have thousands to many thousands of people working from home, so centralizing your security aspect with a high-speed connection is probably the way moving forward.

    Mike Vizard: What impact does that have back on the core networks? I mean, if everybody has suddenly got more bandwidth at the edge, does that have a cascading effect up through the rest of the network infrastructure? Do I need additional core routers or networks? How will this play out in your mind?

    Brian Lavallée: Yeah, _____. Content is created and consumed at the edge, and that’s from humans or machines ‒ think sensors, cameras, and so on. Definitely, as we open up the access ramps, 5G is a way of opening up the wireless access ramp, plus you have a variety of wireline broadband technologies for the home, even the offices. For sure, it has a knock-on effect into the core network because, if you think about it, most of the content and applications that you access, whether it’s on your smart phone, your laptop, tablet, or whatever device you’re using, it’s sitting on a datacenter somewhere. That could be a datacenter close to you, an edge datacenter maybe sitting in the same city as you. It could be a datacenter on the other side of the world sitting in Norway or Sweden or Finland.

    Mike Vizard: I’m feeling like a lot of the applications that people are starting to build, consume data and analyze data at the point at where it’s created more, it’s more happening out at the edge. Is there a lot more sensitivity around latency? Will the laws of networking physics come back and bite us soon, and are we seeing new classes of applications?

    Brian Lavallée: Yeah, and that’s a good question because it leans into the topic of discussion, one of the hotter ones today, which is edge computing or edge cloud. By putting storage and compute access closer to the end-users ‒ again, those end-users could be humans or machines ‒ it does inherently reduce the latency only because you have a shorter physical distance to travel. But, we have to remember latency is not just about distance, it’s about the amount of network nodes that are sitting between you and your content, so the more network devices you go through ‒ switches, routers, and so on ‒ the more latency is incurred and accumulated. Pushing the storage and compute closer to the edge with high-speed connections is a very good way of reducing latency, and it also opens up a whole bunch of new applications where latency is a critical factor beyond just increased speed.

    Mike Vizard: I feel like right after the pandemic, we sent everybody home, we gave them their little wireless network, we hooked them up with a VPN, and they accessed the applications in the office. Then, they went out to the cloud and they had this kind of backhauling effect of the network traffic flow. You mentioned SASE. Are we going to change the way we think about how applications are deployed and how we access them, whether they’re up in the cloud? Is the routing concept that we’ve known all these years changing? How do you think we’re going to go forward from here?

    Brian Lavallée: Yeah, so I think the increased adoption of cloud-based services is an unstoppable juggernaut. It is happening. There are security concerns. Our survey that we did, the study, we did show that there was a security concern of moving more and more into the cloud, but the cloud providers, the telecom operators, they’ve done a lot of excellent work over the last few years to address security, make increased security for their end-users. The cloud-based service providers, they realize that security is top of mind above everything else, so I think that will continue going forward. As more and more end-users are accessing cloud-based applications and content, the network becomes a critical factor because the network now is sitting in between you and the content you’re trying to access.

    Mike Vizard: Do you think the bad guys have figured all this out and they’re targeting people at the end point now and looking at these slightly misconfigured networks? Sometimes we’re using fraud RDP protocols. Are they getting it? Are they after us?

    Brian Lavallée: They’ll always be there, nefarious actors, bad actors, whatever you want to call them, so they will always be there, but the cloud providers, the telecom operators, they know this, so they are consistently upgrading, modernizing, and putting increased security capabilities into their network. It’s always going to be a battle of people who want to do not so good things with the network and content, and the people that actually run those datacenters and networks. I think that will continue going forward, it’s kind of human nature, but we’ve made great strides as an industry, and that’s across IT, telecom, and cloud-based services in terms of security. With more and more people from home, I mean right now we’re living in probably the largest working-from-home experiment of our species, and, if you think about it, the network, it has bent in a few places, right?

    Most of the networks are running hotter, but it hasn’t broken. The Internet has not broken. A lot of people early on thought that if everybody moves home, it’s not that you have more capacity coming to the home, but the traffic patterns have changed. During the day, when a lot of people went to school and work, the traffic was to the schools and the head offices, but now the whole traffic pattern has moved into the home. Although a lot of people were concerned, I think the telecom operators deserve a lot of credit. The network has bent in a few places, but it hasn’t broken, and they’ve just learned a lot over the last year, and the networks will just be that much more reliable going forward.

    Mike Vizard: Prior to the pandemic, the carriers were trying to encourage people to offload from the network and use WiFi. Now we have 5G, and people are talking about 6G and who knows what comes after that. Are we getting to a point where we can just run 5G into the home? Will that get cost-effective at some point and we won’t have all these WiFi routers, or will it always be some sort of a balance between 5G, 6G and WiFi and we have to figure it out?

    Brian Lavallée: Yeah, I mean my personal opinion on that, I think it will always be a mix of technologies. I’ve been in this industry long enough to know that a technology network completely disappears, at least not in my career. It always has places of use. The big difference with 5G over 4G LTE and previous technologies, and even WiFi, previous generations of mobile technologies, it brings a lot of new benefits to the table, right? If we look at the faster speeds, this is what gets the most press coverage because that’s what people will see right away, but it also brings much lower latency. We’re talking order of magnitudes lower latency. It connects to a wider variety of connected devices, such as sensors and smart devices, and then we have this whole concept of network slicing, which can guarantee end-to-end performance.

    You can guarantee the speed, latency, and resilience. We haven’t had that in the past with any mobile network generation, and, to a large extent, we haven’t even had that on the wireline technologies. So, 5G coming right into your home, if you think about it, if you’re a network operator, it’s much easier just to send a 5G hotspot, it could be a router, residential gateway to somebody’s home, they turn it on, they plug it in the wall, and it discovers the mobile network and then BOOM, you’ve got one-gigabit-per-second capacity right to your home. That is, I think, the way of the future in many cases, but there are some technical challenges that still need to be overcome. But, most operators are looking at 5G fixed wireless access to the residential, but even businesses as something in their toolkit going forward to compete with wireline technologies.

    Mike Vizard: Do you think there is a rebellion coming among the end-users who are using this stuff? When you hear them, they’re kind of complaining a lot about the experience, so do you think that at some point they’re going to start picking what companies they want to work for based on what kind of work-from-home, work-from-anywhere experience they can get? Will that factor into hiring and retention more than it has in the past?

    Brian Lavallée: Yeah. I mean, the network is critical infrastructure today, especially for the younger generation who were born and raised on having always-on connectivity. I think that will continue going forward. But, as more people work from home, I know we hear a lot of talk about the new normal, what ire the workplace, for instance, or the school systems going to look like after the pandemic subsides? We don’t really know. But, what I think we do know is more people will be working from home. I see it in my personal life, I see it with my colleagues, I see it with friends and family. Their companies are looking at implementing working from home at least a couple of days a week. There are a lot of benefits to the company to do this, as well, so the network will become that much more important.

    I think people will shop around if the provider they have, the network provider, is not giving them the performance that they need, and it will become a highly competitive marketplace. I mean, it is pretty competitive now, but I think it will be that much more so going forward in terms of speed, latency, and availability, the three main things that you need with a high-speed connection to your home.

    Mike Vizard: I might even one day factor networking costs into my compensation packet, but we’ll see what happens.

    Brian Lavallée: There you go.

    Mike Vizard: What is your best advice to people who are on the IT side of this equation, they’re the network managers, they’re security people. What is the conversation that they should be having higher up the food chain to the board of directors about what needs to happen to really enable this next wave of work?

    Brian Lavallée: Yeah, I mean, the higher speed to the home is something that a lot of people talk about. We just talked about it earlier, more people working, playing, and learning from home, so capacity will always be at the forefront of discussions and having competitiveness for an operator with another operator. But, I think increased security features, this could be wrapped around a broadband connection to your home, so rather than just buying a high-speed pipe to your service provider, they would also provide you with SASE type of capabilities, so security, firewalls, and so on. I think looking at bundling, IT services with the connection is definitely the way to go. It is a differentiator, and it is what people will be looking for because if you’re the average home user, whether it’s for playing, learning, or working, you really don’t care what technology you’re buying, as long as it’s cost-effective and it meets your needs.

    I think my advice for the operators is to look at what is available recently, some of the newer technologies ‒ virtualization and SASE technologies and the SD _____, a whole bunch of other technologies ‒ and start to wrap these into a bundle that you solve most, if not all of the needs of the subscriber, and then you could differentiate far above and beyond just a higher speed.

    Mike Vizard: All right, guys, you heard it here. Faster things that are insecure do not necessarily represent progress. Hey, Brian, thanks for being on the show.

    Brian Lavallée: Happy to be here. Thank you.

    Mike Vizard: All right, guys, back to you in the studio.

    [End of Audio]

     

  • How the Cybersecurity EO Impacts DevOps Teams

    How the Cybersecurity EO Impacts DevOps Teams

    Eric Greenwald, general counsel for Finite State, talks with Mike Vizard about how the executive order for securing software supply chains issued by president Biden will impact DevOps teams. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mike Vizard: Hey, guys. Thanks for the throw again. We’re here with Eric Greenwald who is the General Counsel for Finite State, which specializes in cybersecurity around embedded systems. Eric, welcome to the show.

    Eric Greenwald: Thanks very much. Very happy to be here.

    Vizard: The Biden administration is going to save us all from ourselves. We’ve got this whole effort around software supply chain going on. NIST is now trying to define what a critical component of a software supply chain exactly is. That has been a mystery to many of us for a long time. So maybe you could sort this out for us a little bit. What exactly do they mean and what are they looking for?

    Greenwald: Sure. Well it’s a little bit complicated because I think the conventional understanding of what is critical software is a potentially very broad and malleable concept. What NIST is trying to do is narrow the focus a little bit mostly so that it can phase the implementation of the executive order. I think if you look at some other efforts at imposing standards for software security or security in general that there’s been a rollout and the standards weren’t necessarily drafted in a way that made sense or was easy or low cost to implement, and so what they’re trying to do is avoid those pitfalls and do a rollout that starts with a narrower scope but then eventually expands I suspect eventually to pretty much the majority of the universe of software products that the government buys.

    Now where is it going to stand when the executive order actually begins implementation? That’s what this initial definition is meant to establish. But if you look through what NIST has put out so far, it’s not 100 percent clear, and I think we’re going to get some additional guidance both from NIST and also the executive direct some other departments and agencies to put out some additional guidance. The NIST definition that they put out back on the 25th of June includes a proposed set of categories of software that would be defined as critical under the executive order, but it’s not a definitive list.

    I believe it’s CISA from DHS that’s charged with putting out a definitive list somewhere down the line in the implementation of the executive order. I can’t remember the exact date. But in another 30 or 60 days we’ll see a definitive list of those categories from CISA.

    Vizard: Well, are they doing this out of their concern for us all or are we going to get in trouble at some point? Is somebody going to call me up as a developer and say, “Hey, you’re not protecting these critical components and you’re about to be fined or something bad is going to happen”? So what’s the stick that goes with the carrot.

    Greenwald: So the first stick that gets wheeled in is by the Office of Management and Budget, that is going to use it to compel the departments and agencies that are buying software from vendors out there in the private market that they can only buy software that meets the definition of critical software if it has passed the technical requirements that will eventually be promulgated under the executive order. So the first line of people potentially getting in trouble are the departments and agencies for failure to actually implement the EO’s requirements. Now indirectly, what’s going to happen is as the departments and agencies attempt to enforce the standards under the executive order is that they will select software vendors based upon whether those vendors are meeting the technical requirements. So there’s this trickle-down effect that again it’s going to go through those vendors that are selling directly to the government, but then it will also impact all the various companies out there that are providing components to those vendors that sell to the government.

    So it’s not just going to impact vendors who sell directly to the government. What’s more, it’s going to go even further beyond that because I think especially if people start to think that the standards promulgated under the EO are sensible, are a good way to actually impose tighter security requirements, you’re going to see them adopted more broadly and made mandatory not just for those companies that are selling to the government. But you might see industry groups adopting them, you might see a lot of companies as they are buying software telling their vendors, “Hey, we want you to meet these requirements that have been promulgated under the EO. They’re not required by law to, but we’re requiring you under our contract to meet them.” And you might even see insurance companies start requiring them as a prerequisite for obtaining cyber insurance coverage.

    Vizard: I’m not a lawyer, but sometimes when I do look at these regulations I do notice there’s a common theme between them, almost to the point where I feel like somebody kind of copy and pasted something from one into the other. Is that how things work? People kind of look at one agency and say, “Well thanks for taking the lead on this,” but then they just implement it into their regulatory framework?

    Greenwald: So the best analog to offer on that is if outside of the cybersecurity realm is environmental standards, particularly auto emissions standards. You look at California that leads the way in auto emission standards that it imposes on automobiles sold in California. You see a lot of other states adopting those standards as the model. Not all states, by any measure. But the interesting thing is that car manufacturers can’t just meet those standards to sell automobiles in California.

    They’re going to meet those standards for all automobiles sold in the United States and probably other parts of the world too. Switching to an analog from the security world, you look at the NIST framework. The NIST framework, all voluntary. Nothing about it is mandatory. It’s also not specific technical requirements. So it’s a rough analog.

    But if you look at what happened with the NIST framework you see all sorts of contracts that require compliance with the NIST framework. You see other industry groups or even – and again, in the insurance industry, a lot of insurance companies want to know before providing you with cybersecurity insurance coverage do you meet the basic requirements or the guidelines promulgated under the NIST framework. So I think to your copy and paste point, I think yes, it definitely does happen. And my first hope is that the technical standards promulgated under the EO will be sensible and actually promote better security. My second hope is that if they do they get adopted beyond just procurement for the federal government.

    Vizard: Do you think that the compliance process can be automated as we go forward or is this going to be a lot of manual reviews of code? We’re all hoping or looking for – compliance-as-code is kind of the buzzword of the day in the DevOps space. Do you think we can code our way through this?

    Greenwald: So I’m going to avoid getting too deep into technical issues because I’m a lawyer first and a technology guy second, but I’m more technology policy than engineering, for example. My feeling is that the only way we’re going to be able to implement the technical requirements under the EO in a manner that is efficient and effective, and not too costly I should add, is by automating the process. I will note that part of the approach that Finite State takes to this is automating those software reviews, the scanning for vulnerabilities and assessments of what is actually in the software because that is – number one, doing it once manually is labor intensive. Under the EO, my expectation is that you’re going to see requirements to do it repeatedly, and I think the ideal is doing it with every update or at least even if the updates have a long periodicity doing it more frequently than the updates.

    Or let me just say this – I think that the companies that are able to run their security checks on their software regularly are going to be at a competitive advantage as they approach procurement officers in the federal government to buy their software. And the same thing I think is going to apply more broadly across the industry, that the more frequently you can do these security scans the greater your competitive advantage. And there’s just no way to do it frequently without automating it.

    Vizard: We talk a lot about DevSecOps in our world these days. I wonder if this is just going to force that issue where I might as well start biting this bullet now because one way or another the government’s going to kind of drive me towards it whether I like it or not, so maybe now’s the time.

    Greenwald: Yes. Absolutely in two things. The first is that the EO specifically calls for the promulgation of technical standards for secure development of software. The second is, to your point, my view, what I advocate for companies that are looking at the EO and saying, “Hm, where’s this going, who is this going to apply to?” that if you sit around and wait for it to become mandatory for your company and/or your products, that you’re going to be way behind the power curve and that these companies that are looking at this need to start developing a plan, an aggressive plan, to develop securer software development ops, to implement a software bill of materials – and again, we’re going to see very soon where the technical standards for the software bill of materials will land.

    So people I think will be able to start jumping on that soon. And third, having transparency about your security measures, whether it’s software development or testing, that are accessible to anybody buying your software or using your software. And just to add a last point on there, that being able to do that on a repeated basis where the test results can be validated is going to be very important for companies who, again, want to maintain a competitive advantage in the marketplace.

    Vizard: And I suspect that just because I wrote my code before the rules were actually implemented won’t be much of a benefit to me because they’ll expect me to go back and fix stuff that’s in production.

    Greenwald: That’s absolutely right. So number one is that for any software that the federal government procures following the date that the EO is promulgated, which was I forgot now, like early May, any software procured after that date forward has to meet the EO’s requirements, again, if it falls under the critical software definition. I’ll say something about that in a moment. But the other is that eventually the EO expects OMB to impose those same requirements on critical software that is legacy, that predates the promulgation of the EO.

    As a reference, quick note on if your product meets the definition of critical software. As I noted initially, the definition is being drawn somewhat narrowly. Frankly, I think it’s fairly broad as put out by NIST just a week ago. But again, it’s the initial phase and the definition, the scope, is going to get broader, and I would expect it to end up being quite broad at the end of the day. What day that is, is hard to say. But a key to note is that in the frequently asked questions in the NIST definition that they issued last Friday, they specifically say if a procurement officer wants to apply the EO’s requirements to something that doesn’t meet the definition of EO critical software, they can go ahead.

    There’s nothing that prohibits them from doing so. And if I’m a procurement officer and I’m thinking, okay, I’m buying software today. I know that eventually it’s going to have to meet the EO’s requirements. Why am I going to buy something where I’m worried about it meeting the EO requirements? I’m going to buy something today that is going to give me no headaches down the road in terms of whether it actually meets those requirements.

    And what’s more, if you’re buying software, you’re looking at 10 different products and three of them meet the EO’s requirements, to me that’s an indication that those products are safer. And so I think that you’re going to see procurement officers for a number of reasons gravitating towards those companies whose products meet the EO’s technical requirements.

    Vizard: Yeah. I guess I’m a little more worried about how granular it might get, because we have all these libraries and microservices that people build and then they deploy, and the definition of how that thing may become critical could change over time and what I thought was inconsequential suddenly is critical.

    Greenwald: Well again, and as I said at the top, to me if you’re trying to establish a conventional definition of what’s critical, it’s really hard to circumscribe that narrowly. Anything that has access to a system that you might consider critical, should be considered a critical component. If you’re thinking about what’s the conventional understanding of critical, yes, it’s enormously broad. Again, NIST is trying to start a little bit more narrow and expand later, but I don’t think anyone can feel confident if they have a product, unless it’s something that where there’s just no argument that it could ever be construed as critical, that they should be looking at the EO requirements and figuring out a way to comply with them – well I was going to say comply with them now – we don’t have the requirements yet.

    The technical requirements haven’t been promulgated. But as we start to see which way the wind is blowing, where these are likely to land, companies should be looking to develop a plan to meet those requirements where we expect them to land. And again, not just those companies that sell software to the federal government. So the granularity of the definition, to me I don’t want to go so far as to say as it’s irrelevant, but I think that software vendors of all stripes, whether it is the obviously most critical component of an operating system or something that’s not so obvious, that they should all be thinking about how they’re going to comply. There’s a separate question about granularity, and that is how granular are the technical requirements themselves?

    That remains to be seen. I don’t have a good sense as to how specific and how technical NIST and the other agencies are going to get. But I have a lot of confidence in NIST because they have very good experts in house and they also have spent a lot of time developing relationships with the private sector, making sure they understand what the private sector needs, what really hurts the private sector – and I should say hurts them unnecessary, because there’s no way we get to a more secure software landscape, whether for the federal government or more broadly, without enduring some pain and some cost. You can’t wish your way into better security.

    Vizard: Cool. What’s your best advice to folks then right now? What should they be thinking about, what should they be doing, and how do I get ready?

    Greenwald: So the first thing I would say is if you don’t already have a software bill of materials for your products, that you should start moving in that direction and quickly. As I said, I think it’s just in another week or so that we’re going to see the standards for an SBOM promulgated. When that happens, it’ll give you a very specific target to go for. But there’s no reason not to start now in moving towards that. So that’s something that I think people can start working on today. I think it’ll be a little farther in the future before we start seeing again the specific technical standards being promulgated.

    But I would be, number one, keeping an eye on what’s happening with the various bits of guidance and rules and regulations that are coming out of the EO implementation process, so tracking it closely. Second, if you’re looking to what you can do right now, start looking at generally accepted practices, for example, for secure software development. Because I strongly suspect that where NIST lands is going to be pretty close to what are generally accepted best or very good practices with respect to secure software development, and the same thing for security testing. So we’re a little early in the process to be able to say do A, B, and C specifically.

    Again, within a week or two we should have a little bit of that specific A, B, or C with respect to the software bill of materials. It’s going to take a little bit longer before we get those technical specifics for software development and testing. But again, I think that we can expect NIST to hue to what are already generally accepted as good or best practices in those arenas.

    Vizard: Alright. Like it or not, secure software is on the way. Eric, thanks for being on the show.

    Greenwald: You bet. Thank you for having me.

    Vizard: Alright. Back to you guys in the studio.

    [End of Audio]

  • 2022 Will Be the Year of the Cyber ‘Shift Show’

    2022 Will Be the Year of the Cyber ‘Shift Show’

    As ransomware continues to plague organizations across industries, remote work continues and innovation brings with it new threat vectors for bad actors to exploit, 2022 is poised to be another messy year in cybersecurity.

    In July 2021 alone, organizations lost $45 million to ransomware. What’s more, ransomware costs are projected to reach $265 billion by 2031. The firm Cybersecurity Ventures predicted that “there will be a new attack every two seconds as ransomware perpetrators progressively refine their malware payloads and related extortion activities.” But ransomware isn’t the only cybersecurity concern business leaders should be thinking about heading into the new year.

    As businesses increasingly turn to digital channels like applications and websites to drive everyday business and customer interactions, those endpoints present new threat vectors for bad actors to potentially exploit. According to Okta’s 2021 Businesses @ Work report, large organizations (think AWS, Zoom, Box) deploy an average of 175 consumer and developer-facing applications, with smaller companies averaging slightly less at 73.

    What’s more, upticks in malicious activities like application cloning, credential harvesting and app spoofing will continue to cause headaches. In 2021, organizations and consumers across all sectors were forced to confront new and emerging bad actors in cyberspace. One example: The Android banking Trojan SharkBot (first discovered in October 2021), could implement overlay attacks to steal login credentials and credit card information and could intercept banking communications sent via SMS. To date, the botnet is thought to have targeted banking applications and cryptocurrency exchanges across the UK, U.S. and in Italy.

    But there is a way that organizations can bolster their cybersecurity wherewithal today to future-proof their business against the cybersecurity threats and concerns that will proliferate in the new year: It starts with “shifting left” and embracing DevSecOps within your organization.

    Bracing for Impact

    One of the ways organizations can better prepare and defend their organizations against the rise of cyberattacks to come is by adopting a developer security philosophy known as shifting left. In other words, building security into your DevOps strategy from the start. In industry circles, this practice is also known as embracing DevSecOps.

    DevSecOps involves cultivating a flexible partnership between engineers, operations and security teams to build security into all DevOps processes. Essentially, aiming to mitigate the bottlenecks of older security models on the CI/CD pipeline. DevSecOps also requires increased communication and collaboration between development, IT and security teams to ensure that security practices like testing are done in iterations throughout the code development life cycle. According to Gartner, by 2022, 90% of software development projects are projected to leverage DevSecOps practices—a 50% increase from 2019.

    But to be sustainable, cybersecurity needs to be embedded into all facets of the DevOps process—from production to testing to deployment. But even then, it’s important to remember that DevSecOps alone isn’t a security silver bullet. It’s a starting point. And as cybersecurity becomes all the more essential to bolstering business success and resiliency, it’s the least your organization should be doing in 2022.

    DevSecOps Alone Won’t Cut It

    While DevSecOps serves as a mission-critical foundation for scaling business resiliency, it won’t equip your organization to withstand the ongoing onslaught of attacks in cyberspace alone. Since most of the time, businesses are fighting nations in cyberspace—and far too often, that’s a losing battle.

    In 2022, as threat vectors widen and worsen, it will be essential for organizations to innovate with cybersecurity top-of-mind, across all facets of the development, deployment and production pipeline. Adopting DevSecOps practices across your organization, or shifting left, is one way organizations can bolster business resiliency as we head into yet another unpredictable year in cyberspace.

  • Infrastructure Access Management a Growing DevOps Priority

    Infrastructure Access Management a Growing DevOps Priority

    Organizations plan to address access management over the next 12 months, as the need to secure and streamline infrastructure-wide access controls serves as a prerequisite to other initiatives, like zero-trust.

    This was one of the key findings of a survey of 600 DevOps professionals conducted by Pollfish and sponsored by strongDM. The report also found that legacy access processes created severe team inefficiencies.

    These inefficiencies require intensive time and resources to fix and block agile development practices: Nearly nine in 10 organizations surveyed said they required two or more employees to review and approve access requests and that those could take days or weeks to fulfill.

    The survey also indicated that organizations continue to use access management practices that are not secure and that make it difficult to track and audit users and permissions of critical business systems.

    Tim Prendergast, CEO of strongDM, said as more jobs become technical, there’s a bigger need to deliver access to more people–and that can have a severe impact on a company’s ability to remain secure. He explained that when 65% of organizations are reporting their teams used shared logins—and over 40% used shared SSH keys—there’s virtually no way for you to know who is in your infrastructure or the havoc they may be wreaking.

    “This makes it difficult to pinpoint any leakage or loss because you have 20 copies of your house key floating around,” he said. “It’s an example of the trade-off most organizations make when it comes to speed and ease of access versus ensuring that access is secure.”

    Survey respondents said their biggest challenges were the time required to request and grant access (52%) and the task of assigning, rotating and tracking credentials (51%).

    Hurry Up and Wait

    “Using current approaches to access means you’re hiring these high-paid, technical resources and telling them to hurry up and wait,” Prendergast said.

    Nearly half (47%) of respondents said they struggled with onboarding employees and contractors and Prendergast pointed out that one in four organizations said simply getting approval for access required a process that involved four people.

    “Think about that—in 25% of organizations, you have technical resources basically twiddling their thumbs while they wait to get access to this database or to that Kubernetes cluster,” he said. “Now multiply that by however many databases, servers, employees and third-party vendors that you have. And that’s not even counting when new technologies like Kubernetes are added to your infrastructure. Eventually, even just the frustration of your team as they wait for access becomes a liability.”

    2022: A Year of Convergence

    Prendergast predicted 2022 will see DevOps and security converge beyond what we’ve already seen with DevSecOps, where it has been heavily focused on shifting left and bringing security into the development cycle earlier.

    “This convergence will be marked by new workflows, technologies and solutions that not just improve security, but that also improve the development cycle,” he said. “One great example is optimizing infrastructure access—when done right, you can improve your security posture with zero-trust methodologies while also making it easier for DevOps teams to access systems quickly and easily.”

    He added that two of the biggest workforce dynamics facing zero-trust are remote work and the Great Resignation.

    “You used to have this environment where you’d have to be physically present or on the VPN to have access—remote work broke that,” he explained. “And now you also have this large number of employees leaving their jobs. Do you know what systems they had access to? How do you know if all of that access has been turned off? What happens if they were using shared credentials?”

    Prendergast said that’s why addressing access is critical to meeting this challenge and getting to modern security—if you don’t know who has access to what or what they can do in each system, you can never get to zero-trust.

    “Organizations need to find a way to understand the relationship between each technologist and each technology and then be able to track and audit those relationships,” he said. “Until you do that, you’ll have a really hard time getting to zero-trust. These are the table stakes for modern security.”

  • Predict 2022: Back to the Future

    Predict 2022: Back to the Future

    After a year of innovation, rapid digital transformation efforts, new challenges and settling into a new normal, it is time to look back at all the lessons learned and look forward to the future. What does 2022 has in store for us? Will 2022 be a breakthrough year in terms of progress and opportunity? At Predict 2022 Virtual Summit, taking place Jan. 19-20, top industry leaders will share their speculations on what the future holds in the realms of DevOps, cybersecurity, digital transformation, cloud-native and IT.

    Predict 2022 is a free virtual event featuring a conference lobby, presentation theater, expo hall and more. This event is a great opportunity for networking and learning about the trends, technologies and looming topics that could have the most impact on technology in this new year.

    Predict 2022 features a stellar lineup of industry experts, including:

    • Tracy Ragan, CEO and co-founder at DeployHub, CDF board member
    • Mark Miller, senior storyteller at JupiterOne
    • Mike Jones, H4unt3d Hacker Podcast, content creator at Knight Ink
    • Caroline Wong, chief strategy officer at Cobalt
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Donovan Farrow, CEO at Alias
    • Nicole Dove, CIA, CRMA, business information security officer at WarnerMedia
    • Niladri Choudhuri, founder and CEO at Xellentro Consulting Services LLP
    • Emmet B. Keefe III, operating partner and founder at Insight Partners
    • Matthew Guarini, VP, senior research director at Forrester
    • Mike Vizard, chief content officer, GM/editorial director at Techstrong Group/Digital CxO
    • Mitch Ashley, CTO at Techstrong Group and principal at Techstrong Research
    • Ori Inbar, CEO at Augmented World Expo
    • Thomas Krane, principal at Insight Partners
    • Ali Khan, partner, US Consulting Solutions at PwC
    • Jim Walker, principal product evangelist at Cockroach Labs
    • Keri Pearlson, executive director at MIT (CAMS Research Consortium)
    • Russ Finney, lecturer and director of MIS Undergraduate Programs at The University of Texas at Austin McCombs School of Business
    • Marnie (Huss) Wilking, CISO, advisor, board member at Wayfair
    • Patricia Titus, chief privacy and information security officer at Markel Corporation
    • Rob Zuber, CTO at CircleCI
    • Steve Chin, author and VP of developer relations at JFrog
    • Whurley, founder and CEO at Strangeworks, Inc.
    • Chris Hughes, co-founder and CISO at Aquia
    • Tracy Bannon, senior principal, software architect and DevOps advisor at MITRE Corporation
    • Christina M. Rhylander, acquisition and policy specialist at MITRE Corporation
    • Daniel Elkabes, vulnerability research team leader at WhiteSource
    • Vanessa Pegueros, board member and cybersecurity leader at OneLogin
    • Alan Shimel, founder and CEO at Techstrong Group
    • Charlene O’Hanlon, CCO at Techstrong Group

    Attendees will be able to interact with sponsors and peers, download information and participate in raffles, giveaways and other interactive activities.

    MediaOps CEO and devopsy.kinsta.cloud Editor-in-Chief Alan Shimel will also be announcing the 2021 DevOps Dozen² Awards winners during the event.

    To check out the full agenda and to register, please visit the Predict 2022 website.

  • Best of 2021 – Torvalds’ Bug Warning is a Lesson for Linux Users 

    Best of 2021 – Torvalds’ Bug Warning is a Lesson for Linux Users 

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the third in our series of the Best of 2021.

    Linux does, occasionally, raise security concerns. While many users see it as the most secure, robust and versatile operating system available — that’s this writer’s opinion, as well — security precautions still have to be taken.

    A recent, widely publicized case illustrated this point; Linux creator himself, Linus Torvalds, warned against the use of the Linux 5.12 release. He described a “nasty bug,” and wrote that the situation is a “mess,” due to the use of swap files when adding Linux updates. This nasty bug, in fact, had the potential to destroy entire root directories.

    Some of the main takeaways following this “mess” include: tread very carefully when installing early Linux releases, especially those that involve swapping files instead of partitions, and especially, despite Linux’s well-known security advantages, avoid becoming complacent, because Linux security is not always foolproof.

    Hence, while the “state of Linux security today is quite good, and has evolved in a positive way with more visibility and security features built, like many operating systems, you must install, configure and manage it with security in mind; that is how cybercriminals take advantage, [via] the human touch,” said Joseph Carson, chief security scientist and advisory CISO at Thycotic, a provider of privileged access management (PAM) solutions.

    A Patch for Nastiness

    As Torvalds noted a few weeks ago, “most people don’t use a swap file, but a separate swap partition and the bug in question really only happens when you have a regular file system, and put a file on as a swap.”

    “The bad news is that the reason we support swap files in the first place is that they do end up having some flexibility advantages, and so some people do use them for that reason. If so, do not use [release candidate] RC1,” Torvalds wrote. “Thus, the renaming of the tag.”

    After issuing the warning, Torvalds released a patch that he says prevents the bug from destroying swap file systems. However, it may have already been too late for early adopters of release 5.12. Ubuntu, a leading Linux distro, can swap files by default.

    “It is nasty bug if you are still using swap files,” Carson said. “If you do still use swap files, then you could be impacted, resulting in potential data loss or a corrupted system.”

    DevOps teams – or anyone else running Linux and installing patches, whether on multi-servers or on individual workstations – still need, of course, to follow strict best practices. “Like any operating system, security depends entirely on how you use, configure or manage the operating system,” Carson said. “Each new Linux update tries to improve security; however, to get the value, you must enable and configure it correctly.”

    Linux Goodness

    The fact that Torvalds was so forthcoming about the bug, as well as the level of transparency that the Linux kernel offers, also demonstrates one of the many reasons Linux remains popular. Given that the Linux kernel, in one variety or another, is used “not only in about 50% of the internet servers of the world, but also in a substantial part of all our smartphones, it is good to see this level of transparency at ‘root level,” said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), which providers cybersecurity and compliance software.

    “The security of Linux is based on its transparency; the ability to review the code of a distribution,” says Schrader. “Quite often forgotten is that transparency also involves talking about the mistakes, the errors, those nasty bugs.”

    Citing National Institute of Standards and Technology (NIST) vulnerability database statistics, Schrader described how, compared to the Windows family of desktop and server operating systems, for example, the Linux kernel shows better results for overall vulnerabilities. The number of vulnerabilities have also declined over the past four years, while Microsoft’s operating systems do not display the same trend, according to NIST’s national vulnerability database.

    Since Linux’s famous kernel is open source and transparent, it is possible to extrapolate that there are a greater number of potential vulnerability watchdogs compared to those monitoring vulnerabilities in closed systems. Some may argue that Microsoft has been, at times, less successful at detecting vulnerabilities and issuing much-needed patches.

    However, Linux users still must remain vigilant.

    “Still, for any of the Linux distributions, anyone using the early release candidates — RC1 in particular — should make sure that their own development or build process is undergoing change control, so that no mishaps will transfer the nasty bug into a production environment,”  said Schrader.

  • Datadog Cloud Security Platform Advances DevSecOps

    Datadog Cloud Security Platform Advances DevSecOps

    Datadog has launched a Datadog Cloud Security Platform that promises to advance DevSecOps by identifying potential threats using the same agent software many DevOps teams already rely on to instrument applications.

    Renaud Boutet, senior vice president of product for Datadog, said organizations that rely on the Datadog software-as-a-service (SaaS) platform can now more easily invoke security services based on the same data model used to observe applications.

    The security services provided by Datadog include a cloud security posture management (CSPM) offering that identifies misconfigurations and applications that are not compliant with industry standards such as the Payment Card Industry Data Security Standard (PCI DSS).

    A cloud workload security (CWS) offering, meanwhile, detects threats to production workloads by monitoring file and process activity, while a monitoring tool identifies threats to cloud environments by analyzing operational and security logs. It also provides integrations and threat detection rules that are easy to extend and customize.

    Finally, there is an application security tool, currently in beta, that identifies and blocks attacks that target code-level vulnerabilities, such as SQL injections and cross-site scripting (XSS) exploits.

    Boutet noted that many DevOps teams are reluctant to roll out security platforms that require them to deploy, manage and update an additional set of agents across their application environment. Datadog is now effectively unifying application observability and security in a way that makes it simpler for those DevOps teams to embrace DevSecOps best practices, added Boutet.

    In some cases, the dashboards surfaced by Datadog will be employed by DevOps teams that have assumed responsibility for cybersecurity as part of an effort to shift more responsibility for application security further left, noted Boutet. In other instances, cybersecurity teams will be able to view the same alerts shared with their DevOps colleagues, he added.

    Pressure to address DevSecOps is mounting in the wake of a spate of high-profile software supply chain breaches. While the majority of organizations have not been breached, questions are now being asked at the boardroom level as concerns over application security increase. Many organizations are wondering if they should slow down the pace of application development to ensure better security and to what degree.

    Regardless of the path forward, awareness of application security has never been higher. An executive order issued by President Biden calling for improvements to security will likely have a cascading effect across not just government agencies but also on organizations that do business with those agencies. One way or another, DevOps teams and cybersecurity professionals will be required to work more closely together. The challenge is striking the right balance between security and productivity. Most developers are never going to become world-class security experts. Conversely, most security professionals know next to nothing about coding. That doesn’t mean, however, that efforts shouldn’t be made to educate both camps as much as possible. After all, even a small amount of education can have a profound impact when most of the attacks being made against applications are not especially sophisticated.

  • The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    What Happened

    As part of a bug bounty, the security researcher Uzsunny found a critical vulnerability on the Shopify platform. The vulnerability allowed the attacker to assign himself as a “collaborator” to any store on Shopify without approval from the store’s manager. Collaborators have full access to perform any action on the store, including reading customers’ data, changing inventory and more.

    Technical Details

    The Shopify Partners Program allows experts to connect with Shopify store managers and provide them services such as design and web development. A single expert can be a collaborator on different stores.

    The process of requesting “collaborator” access to an existing store contains three steps:

    1. The expert enters the store URL.

    2. The store manager receives an email about the access request.

    3. Once the store manager approves the request, their browser sends an API call to:

    This API call approves the access request by the expert and converts him to a “collaborator.”

    The problem: The code did not validate that the API call was triggered by a store manager. In fact, any user could call the API endpoint and approve the access request, even if they don’t have the right privileges.

    Using this technique, Uzsunny managed to “log in to any store with full permissions.” For his troubles, Uzsunny received a $20,000 bounty from Shopify, which reported: “We tracked down the bug to incorrect logic in a piece of code that was meant to automatically convert an existing normal user account into a collaborator account.”

    Why Can’t Current Security Solutions Detect It?

    The exploit in step #3 looks simple and requires only a single HTTP request: “POST /admin/settings/account/approve/<id>.” Authorization exploits usually look legit from a WAF/RASP perspective; they don’t contain suspicious payloads or characters, weird HTTP headers or abnormal structure. In fact, if the same exact HTTP call was sent by a different user who is a store manager it would be completely legit.

    In order to understand authorization exploits, a much broader context is needed. It’s simply not enough to look at a single HTTP request.

    How Traceable Solves the Problem

    Our approach to detecting API attacks is very different. In a nutshell, we observe the data that passes through the API and the microservices of the app. We then use our machine learning algorithms to discover the application’s business logic. We get full visibility into the users and their roles, the API endpoints they communicate with and the resources the endpoints interact with behind the scenes. Now we can create a baseline understanding of a legit user’s flow through the system.

    The visibility into users helps us understand that the client is actually a guest user, and the visibility into the API helps us to recognize that the endpoint is an admin endpoint that should be used only by store managers. Then we can simply block malicious abnormal activity.

    With this approach, we can detect the most sophisticated and subtle API attacks, including broken function-level authorization (BFLA).

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • Best Practices for Cloud Incident Response

    Best Practices for Cloud Incident Response

    Cloud computing is now mainstream, with almost all organizations running at least some resources in the public cloud—whether software-as-a-service (SaaS), platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS). Security teams have been scrambling to adapt to cloud environments, and with the growing adoption of DevSecOps, they are working together with DevOps teams to secure cloud systems from the ground up.

    As your organization discovers the best way to secure its cloud investments, you also need to develop an incident response strategy for the cloud. Even if your cloud security controls are perfect (and they aren’t), attacks will happen. Knowing what to do during an attack and preparing teams for incident response can be the difference between an incident quickly contained and resolved, and a multimillion dollar disaster.

    What Is Incident Response?

    Incident response enables organizations to make sure they are aware of security incidents and can respond in time to limit the damage to their systems. The objective is to block attacks and prevent similar attacks in the future.

    The SANS Institute’s six-step incident response process provides a structured framework for security incidents. These steps are:

    Prepare—establish security policies, carry out risk assessments, determine which assets are sensitive and establish an incident response team.
    Identify—monitor your systems to detect anomalous activity, identify real security incidents and investigate the severity and type of threats.
    Contain—conduct short-term containment procedures to stop the spread of the threat, followed by long-term containment, such as applying temporary fixes and rerunning a clean system.
    Eradicate—identify the root cause of the incident, remove malware and implement measures to prevent future attacks.
    Recover—restore your production systems and apply measures for preventing further attacks. Test and monitor recovered systems.
    Learn—perform retrospective analysis within two weeks of the incident with complete documentation evaluating containment efforts and determine how you can improve the incident response process.

    How to Prepare Your Cloud for Incident Response

    There are several ways you can prepare your incident response team and your cloud environment for more effective incident response:

    Establish response goals—determine incident response objectives in consultation with stakeholders, legal advisors and organizational leaders. Common goals include problem control and mitigation, restoration of affected resources, and storage of data for evidence and attribution.
    Use the cloud to respond—ensure your cloud resources include the tools and resources you need to respond to an incident. For example, ensure you have robust cloud-based logging and monitoring systems, and set up cloud-based backup and disaster recovery so you can rapidly restore affected systems.
    Determine your requirements—keep copies of logs, snapshots and other evidence in a centralized cloud account. Apply mechanisms to enforce retention policies. Use tags and metadata to maintain visibility and connect logs and cloud resources to organizational units, projects or corporate systems.
    Use a redeployment mechanism—if a security anomaly is caused by a misconfiguration, you should be able to remediate it easily by redeploying the resource with the appropriate configuration. Ensure the response mechanisms can be executed multiple times if necessary.
    Leverage automation—after identifying recurring problems and incidents, automate as much as possible and break them down programmatically to build response mechanisms for common situations. For example, use the mature auto scaling service on AWS or Microsoft Azure’s infrastructure-as-code (IaC) capabilities. This is much easier on the cloud than it was in an on-premises data center. Ensure you use human response only for unique, new or critical incidents.

    Effective Incident Response in the Cloud

    Use the following tips to improve your ability to respond to security incidents in a public cloud environment.

    Shift Your Focus

    Cloud environments require you to monitor different elements than you would in traditional on-premises environments. In the cloud, you should focus on applications, APIs and user roles. Consider how incident responders can operate successfully in a cloud environment, and what tasks they may need to perform. The incident response team must have proper access and visibility into your systems so they can detect, remediate and prevent attacks.

    Integrate Alerting and Incident Management Tools

    The security team must have direct access to supporting data to triage alerts and classify incidents. To this end, security alerting tools should be integrated with any incident management tools you use, like PagerDuty and Slack, for example. This enables security alerts to directly reach the existing tools and workflows used by your teams. Responders won’t have to alternate between tools to see what is happening.

    Build an audit trail to capture the response to each alert, which will provide visibility and accountability and help you refine your response processes. All actions taken in security tools must be visible in the relevant collaboration tool, so you can see who dismissed a specific alert and when, and what annotations they made.

    Work with Your Cloud Provider

    Cloud providers usually have an incident response team, but you cannot assume the vendor will handle everything during an event. Be aware of the shared responsibility model, where cloud providers are responsible for securing the infrastructure, while the customer is responsible for data and workloads.

    Make sure you understand the service agreement for your cloud provider and who is responsible for exactly which element of the response. Find out exactly what alerts you can expect from the vendor’s team and how it can support your own team. Having a clear relationship and establishing points of contact can save critical time during an incident.

    Protect Your Logs

    The major cloud vendors provide logging capabilities for their environments, including log files or operational metrics to provide insight into service operations. Logging services may be free or paid, ranging from basic access logs to complete audit and configuration logs. Most cloud logging service will allow you to store logs outside the cloud or on-premises—and it is critical to do so.

    Logs are a useful resource for incident response investigation, and you must ensure they remain inaccessible to attackers. An attacker might be able to compromise your cloud system or services, but they won’t be able to modify or delete your logs. Logs are a protected source of information that can help you identify the attack timeline, targeted systems and the attacker’s IP address. This provides a reliable starting point for investigations.

    Conduct Cyber Range Training

    Organizations often rely on exercises to train or test their security and incident response capabilities. Today, cloud environments provide an opportunity to simulate your production network in a protected environment, allowing your security team to practice their response to real attacks on your network within a safe setting.

    Tools such as AWS CloudFormation allow you to quickly design and deploy training networks that are identical to your actual network. You can keep costs down by limiting the duration of exercises. These exercises may be the best way to prepare your team to respond to attacks in the real world.

    These are the basics of security incident response, preparing a cloud environment for incident response and how teams can effectively react when the inevitable attack occurs. In short, it’s important to:

    Focus on what matters – In the cloud, this is APIs, applications, and identity and access management (IAM) systems.
    Integrate alerting and incident management tools – The cloud provides ample automation capabilities. Use them to respond automatically to common anomalies.
    Work with your cloud provider – You are not alone in the cloud, and teams need to understand exactly which part cloud providers will take in responding to an incident.
    Protect your logs – If logs are exposed to tampering, you will have no way to detect, investigate and respond to attacks. Protect them at all costs.
    Conduct cyber range training – You’ll never really know what it’s like to respond to an incident until one actually happens. Instead of waiting for a real attack, conduct a “cyber range training” or security drill and see how everyone works together in an attack scenario.

    Now, you’ll be better prepared as you move towards a cohesive cloud security strategy for developers, operations, and security teams.

  • What Biden’s Cybersecurity EO Means for DevOps Teams

    What Biden’s Cybersecurity EO Means for DevOps Teams

    On May 12, 2021 President Biden issued Executive Order 14028, also known as the Executive Order on Improving the Nation’s Cybersecurity. This EO covers a lot of ground, and like all executive orders, it instructs agencies of the U.S. Federal Government to perform specific actions. What it doesn’t do is appropriate funding or create industry mandates. That’ll come later, once some of the plenary stages of the EO are complete.

    Despite this, I’m confident that EO 14028 could be as impactful to cybersecurity as GDPR was to data privacy. I’m also confident that the EO has the attention of business leaders who are trying to figure out what it means to them and their teams—DevOps professionals. While the EO has no underlying mandate to private businesses or those located outside the U.S., it does outline a reasonable set of cybersecurity best practices that can be reasonably interpreted as a call to action for greater transparency.

    In this article I’m going to use the terms supplier and buyer, but I don’t mean to imply that money needs to change hands; only that there are producers of software (suppliers) and consumers of software (buyers). If there is one supplier and one buyer, the software supply chain has one link. If that supplier is also a buyer, the chain has two links. For most software, there are many suppliers; in these cases, the supply chain isn’t so much a length of links but more of a mesh of interconnected links.

    The 2021 Synopsys OSSRA report showed that the average audited application had over 500 dependencies, so that mesh is quite complex—to the point where the security practices used anywhere in the mesh are often obscure, at best. It’s this obscurity that attackers can exploit, which is why one of the key tenants of the EO is transparency.

    As anyone charged with operating a piece of software knows, the security testing performed by a supplier isn’t really obvious, but, as a buyer, you assume the supplier has done the right things when it comes to security. But how do you know? Do you know where the code originated from? Do you know what security targets were used by the supplier? If an attacker is actively compromising the application, how would you know?

    These are all very good questions that are reflected in the EO, to varying degrees. Those questions also belie the reality that suppliers test software. Suppliers do, of course, test their software, but what testing techniques did they use and how effective are/were their tools? And, more importantly, how can you confirm that the mitigations and fixes applied to address identified defects were effective for your deployment scenario? After all, it’s not like every supplier is going to provide you with full access to their source code.

    This is where things become quite actionable for DevOps teams that have embraced the principles of operational feedback mechanisms. For those needing a bit of a refresher, that’s the part of the DevOps mobius where lessons learned operating software are fed back into the next iteration of the development flow. Let’s look at two pieces of operational feedback that are mentioned in the EO: least privilege and log management.

    Log management features prominently in the EO in part because logs enable an understanding of how an application is operating. If a supplier provides detailed information about the log structure and flows, it then becomes possible to build alerts in log aggregation services and SIEMs as indications of unexpected operation. That’s the proactive model the EO embraces—as opposed to forensic postmortem log analysis following a breach—but this requires the supplier to provide insights into the log data indicating that the system became compromised. Of course, to provide that type of data, the supplier must have tested their system software in a manner that allows such a log template to be created.

    We’ve heard that software should be developed using principles of “least privilege” for years, but if you’ve ever been asked to run an application as root or had a supplier not detail the precise network ports required by the application, you know there is still work to be done there. The EO specifically calls out cybersecurity techniques like multifactor authentication and zero-trust network access as ways to achieve granular control over how applications operate.

    It is, however, the coverage of Software Bill of Materials (SBOM) that could have the greatest impact for DevOps teams. In effect, the EO stated that suppliers need to tell buyers the origin of all code within an application. While the EO doesn’t specify the elements of an appropriate SBOM, it does instruct NIST to publish the minimum elements of an acceptable SBOM within 45 days of the EO. When combined with the sections on how build environments are created and managed and the security transparency elements elsewhere in the EO, it’s clear that the EO intends to raise greater awareness of how software is created, patched and maintained.

    In the end, Executive Order 14028 sets a high bar for cybersecurity in general—one where everyone involved in the creation and operation of software will need to up their game. I’ve said for years that it’s impossible to patch something you don’t know you’re running, and that remains true. What must be added is that you also can’t reliably secure something when you don’t know how well each component was tested. The EO is prompting us all to take a step toward solving that problem.