devopsy.kinsta.cloud

Tag: devsecops

  • DevSecOps: Deception in Depth

    DevSecOps: Deception in Depth

    Mantraps, tripwires and tarpits … sounds like the start of a solid spy-movie plot, doesn’t it? These are among the many concepts of physical security that are making the crossover to software security.

    You’ve likely heard that security is all about defense in depth—the idea of layering several defensive measures so that their combined effectiveness is stronger than if they were used individually.

    In the case of deception, we are taking tried-and-true warfare approaches and applying them to DevSecOps. According to researcher, deception specialist and popular speaker Herb Todd, there is no rule of law in warfare, and in environments where you put code on the web, you are giving the world access.

    Deception Approaches

    There are two primary approaches to deception in software security. The first is to get attackers to look in places where you have no vulnerabilities. Todd would call this, “Appear weak where you are strong.” This is what honeypots do: offering an attacker a weak-looking target that appears as if doors are unlocked and there’s an opportunity to gain a foothold. All the while, there is no real vulnerability to be found, and the defensive team can be alerted to an adversary on the network.

    The second approach is to isolate or slow down attackers as they progress through your networks and application. One way to do this is to add tripwires throughout. When parts of your web application starts being manipulated in ways that normal users wouldn’t do, you know you have an adversary testing your application looking for vulnerabilities. At this point, you can move them off to a segmented portion of your application or network through the use of a mantrap, or slow them down with a maze or tarpit.

    Provoke Action

    Deception measures hinge on being able to get attackers to take an action. This is the main goal of deception. If we can provoke an action from the adversary, then we can begin to understand them and to track them throughout our system. This creates a feedback loop in DevSecOps for developers, operations and security to determine how many adversaries are currently interacting with the system, what they are attempting to do and how to add new defenses in the future.

    None of the major data breaches you read about start with the organizations saying, “Our security team has been tracking these attackers for weeks.” In fact, it is the exact opposite: We usually learn that the attackers had been inside the system and exfiltrating data undetected for months on end. The organization didn’t know they were under any attack until after their database got dumped on the internet or leaked to the media.

    Start with Tripwires

    Deception sounds great, but how do you go about it? In Todd’s talk on the Modern Security Series, he gave several ideas on how to get started in the case of web application security development. Methods in DevSecOps include adding fake paths to robots.txt and fake hidden fields to your application. When someone hits your tripwires, you log it and fire an alert for the team to investigate. As you gain familiarity with that, moving into tarpits and mantraps begins to make more sense.

    One example that Herb Todd gave in his talk was to add a hidden field of “encrypted-auth” and set it equal to “YWRtaW49ZmFsc2U=”. An astute web developer will notice that this is not actually encrypted. This is a base64 encoding of “admin=false.” When an attacker sees this, they will immediately think, “What if I tried sending admin=true?”

    So the attacker takes the string “admin=true” and then uses base64 encoding to produce “YWRtaW49dHJ1ZQo=” and submits that. Now, if your application receives a value for the hidden field that isn’t the original value or matches “YWRtaW49dHJ1ZQo=”, then you have actionable intelligence to alert on.

    When creating a tripwire is this simple, why stop with just one? Adding small tripwires throughout an application through DevSecOps can be highly valuable to identify more advanced attackers.

    DevSecOps: Making a Practice of Deception

    While deception is beginning to gain favor among AppSec professionals and thought leaders, it’s not yet standard practice by any means. But this should soon change, as  the next year or two see the best security teams adopting deception strategies—and for good reason. With traditional methods such as web application firewalls (WAFs) breaking down in the face of high-volume traffic and more sophisticated threats, security needs to become more creative. Defense-in-depth concepts such as deception have been proven effective in the physical worlds of warfare and spycraft—and when incorporated into DevSecOps, they can be just as powerful for ensuring protection in the digital world as well.

    — James Wickett

  • Malicious Intent: Open Source Developers, Please Protect Your Users

    Malicious Intent: Open Source Developers, Please Protect Your Users

    For the second time in just a few weeks we’re seeing the fallout of missteps taken by publishers of open source components. It was just recently that I wrote about the GitHub id of go-bindata being highjacked. We don’t know for certain if the intentions were malicious, but the risk was obvious.

    Even more recently we find that credentials were compromised for an npm component called conventional-changelog and a malicious version was uploaded that allegedly included a Monero cyptocurrency miner. Anyone who built or installed an npm package depending on the malicious package is now potentially running a miner and worse, potentially distributing it to their downstream users or customers.

    A few months ago people were laughing at a parody of a similar situation describing credit card harvesting via a compromised package. It’s not so funny anymore, is it?

    Open source developers typically thrive in creating something used by millions or billions of other people. This is the fuel that drives us and knowing that you’ve contributed, even in some small part, to the lives of millions of users is amazing.

    Conversely, knowing that you’ve accidentally inflicted harm on those users through careless practices is probably devastating. Yet, seemingly not enough people are thinking about this beforehand while it’s preventable.

    We open source developers and package maintainers are finding ourselves at the frontline of the new battle. Attackers have recognized the power of open source in terms of broad distribution and are seeking to use that against us.

    We must not let them ruin the reputation of the things we’ve built—or, worse, the entire open source ecosystem.

    If you’re an open source contributor or package maintainer: Pay attention to your own digital security as you would if you were protecting millions of others. Because you are.

    — Brian Fox

  • Integrating Security into DevOps: The Benefits and Drawbacks

    Integrating Security into DevOps: The Benefits and Drawbacks

    The efficiency of DevOps for your enterprise will depend on the level of security you integrate in it. The integration of security into DevOps is new to many enterprises, but is highly important because the speed of DevOps can make the apps in development vulnerable to malicious attacks. This can be prevented with the help of right security controls.

    Security and development teams must understand each other’s requirements and goals. Some might view security professionals as the ones who tap the brakes as the DevOps team moves forward. However, the job of security is to manage the risk effectively. To accomplish this, the security team must be integrated into the DevOps process.

    In many companies, this is a completely new methodology, and different structures are needed for different companies. The global security function is a component of the program management ecosystem by one security model. Security is integrated as an essential member of the development organization by another security model.

    Blockchain is the underlying technology behind cryptocurrencies such as Bitcoin and is used to secure the bitcoin wallet. The implementation of blockchain in a company’s DevOps process increases its agility and delivery efficiency, while the integration of security benefits an organization’s DevOps process in multiple ways. However, along with these benefits, few drawbacks do exist. Let’s dig deeper into both of them.

    The Benefits and Drawbacks of Integrating Security into the Program Management Ecosystem

    The program management function has a significant role to play in this model. It ensures that security is in place, and confirms that all the required specifications are documented and met. Security then carries out evaluations and determines what critical issues need to be addressed. In this security model, the security office can address the condition of a wide range of products that the organization delivers in a uniform manner.

    The drawback is that the issues related to security often are listed on a slide for review by executives and noted by the most important person in the development organization. Consequently, the list becomes a road map for “what we must fix” more than a prescription for “what we must make sure the product sticks to before it gets shipped.”

    The Benefits and Drawbacks of Integrating Security into the Dev Organization

    If the security team is a component of the development organization, they must maintain close contact with the global security office. But they can be much closer to the product development. This means they are closely working with feature teams and determining stories that should be planned into the sprints.

    These assessments cannot wait until the end—they must be planned into the first sprint that makes sense. Then, the resulting group of issues becomes technical backlog to prioritize into the following sprints. The goal is to produce applications that are safe for customers and have assessments that are known and can hold up to customer audit.

    However, the local security team must connect strongly to the global security office. Every security team that is a component of the development organization must rise to act as a single brain across all the products; companies cannot have any variance with respect to adherence to mandates, assessments, tools and standards.

    Where to Incorporate Security?

    To enable a continuous security mindset, security must be covered by automated test cases related to security in the continuous deployment/continuous integration process over the following phases:

    • Regular operations – near-real-time automated enforcement and utilization of continuous monitoring.
    • Integration phase – full sanity checks for external/internal endpoints, and make sure any new workloads do not break any of the security policies.
    • Infrastructure creation phase – test utilizing tooling such as serverspec/rspec.
    • Image creation and hardening – as part of the delivery pipeline, automate this phase.
    • Build phase – utilize code analysis.

    Securing QE and Dev Labs

    The final dimension is quality engineering (QE) and development, though they might be forgotten. Both of them have labs in which they make sure all the functionality performs, scales and works. These labs are good targets for intrusion, and security has a major role in the remediation and evaluation of the lab environment.

    Conclusion

    Adopting a DevOps methodology can instigate security vulnerabilities and new blind spots introduced by new systems. But fewer workplace silos and improved communication can help address issues much quicker. Today, security also can be integrated into DevOps using various technologies. It is highly essential to have security integrated into the process, no matter what method works best for your company.

    — savaramravindra

  • DevSecOps: If You Build It, They Will Come

    DevSecOps: If You Build It, They Will Come

    Spring training for Major League Baseball in the United States has begun. Millions of people share my love for baseball; however, the same can’t be said for security and compliance—well, at least not yet. Perhaps one day.

    Much like in the immortal baseball movie, “Field of Dreams,” if you build a friendly security and compliance system, the developers and operators will come. At least, that is the contention of Julie Tsai (@446688), senior director of security operations at Box.

    GettyImages-509936368

    I first met Julie at the RSA conference’s DevSecOps Days three years ago and have been following her musings since. I recently watched Julie’s presentation, “Build It and They Will Come-pliant: DevSecOps in the Real World,” from All Day DevOps. Here is a summary of what I learned:

    Good Architecture Sustains Sound Applications and Security

    Julie’s contention is that you can build a system that might actually bring a little joy to developers and operators, and it starts with realizing that, at the end of the day, we are all looking for good architecture. Good architecture sustains sound applications and security. It makes everyone’s life easier, so we all have a little time for baseball (or football or board games or even curling).

    The good news is that DevOps organizations are ahead of the game. Julie pointed out the old joke, “DevOps … isn’t that just where you give the keys to the developers?” Well, no, and it isn’t a specific tool or deployment. For security, it is about being lean on requirements, building compliance in from the start and integrating it across the development life cycle so you can build something that is secure and performant. Besides these being best practices for developers, they also allow you to use your code and policies to appease your auditors, as compliance is built-in. Bottom line: DevOps puts the rigor around security and compliance.

    It Takes a DevSecOps Village

    Julie pointed out a couple of takeaways from DevOps that help security and compliance:

    1. You can own a problem and be an individual leader. You can think globally but act locally by seeing across the silos and bringing a message of empowerment.
    2. It provides a path toward integration to internalize other groups’ values, bring them into your own words and ways and mutually reinforce and thrive. It also informs how people work together.

    Remove Friction to Scale DevSecOps

    The goal here is to ultimately get us something easier to scale and maintain and be compliant and secure. Julie outlines steps to get you closer to this idyllic system:

    1. Use configuration management because it leads to precision and more unified and verifiable work.
    2. Get rid of whatever you can to eliminate mistake factors. You will also get to a place to streamline workflow so there are fewer mistakes.
    3. Extend infrastructure as code. It can become configuration as policy and your audit trail can connect the intent to the execution.

    DevSecOps: Where Things Go Wrong

    With these in place, Julie contends you need to realize the world isn’t perfect, so you need to build a system that injects security and compliance where it is most effective. To find the areas in the development life cycle that it is important to inject, ask these questions:

    1. Where is someone intending to make a change?
    2. When you are releasing it live into your production stack?
    3. What is happening when something isn’t going as expected? Is it being changed back to where you need it to be, are you monitoring it, or are you doing nothing?

    DevSecOps: String Together Wins

    You also need to make it simple. She quoted Mark Burgess, “IT has a detail sickness,” noting that, “We are often burdened by complexity—we love it and dig right in, but it is important to understand the level of granularity you need. You need to look for the things that can make a critical uplift that gives you an incremental improvement. String together the wins.”

    In the end, Julie said to “try to reach a goal of being visible and streamlined and leverage the automation and technology in a way that is joyful in how we use it. It is not about a rigid process that is going to die soon; it is about what we are trying to bring to the whole world so that we work more efficiently and more technical.”

    The entirety of Julie’s presentation—including some live Q&A—is available here. If you missed any of the other 100 speakers at All Day DevOps, you can find their 30-minute presentations here.

    — Derek E. Weeks

  • DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    Much of the conversation around digital transformation revolves around technology. But the new wave of technology this era has ushered in has also made a big impact on the way organizations, and the teams that comprise them, function.

    This impact on corporate culture has paved the way for the widespread adoption of DevOps, which has broken down silos between developer, quality and operations teams and streamlined the software development process. The next step? Integrating the security team to ensure teams are shipping software that’s actually secure.

    Here are a few ways security teams can better support their developer counterparts:

    Understand How Software is Being Made

    Development teams are under increasing pressure to ship software fast and frequently. Security teams should identify ways to help developers keep up with the rapid software development life cycle (SDLC), while making sure security isn’t sacrificed for the sake of efficiency. Understanding the SDLC for your company is key to finding ways to help that make sense. Have discussions with your development leaders and influential developers to find some ways to win. Create a pilot program with a friendly development team and pour all of your effort into making them successful. Nothing breeds success like success.

    Act as Consultants and Partners

    Developers are taking on more responsibility when it comes to the security of the code they write, which has alleviated some of the pressure put on the security team to secure an entire organization. This has changed the way security teams function and given security professionals the opportunity to act as consultants to their peers in other departments.

    Security team members should approach their developer counterparts with an attitude of enablement. Offering security best practices, problem-solving strategy and general advice will help developers become more confident in their ability to secure the software they build.

    Base all of the above on the security problems they actually have. Don’t preach. Use data from your own application scanning to tailor training. Fill a room with pizzas and developers and talk to them over lunch about problems you can help them fix. Make it conversational. Ask them how they would like to be helped.

    Embrace Ongoing Learning

    Developers have a lot to learn from their security counterparts, but developers can teach security professionals a few things, too. Setting up peer-sharing sessions where both groups can learn from each other will foster an environment of collaboration within the enterprise. Security teams can share threats related to code and specific programming languages and help developers think more like hackers. Developers can share insight into the SDLC and best practices for using code components.

    Combined, the security and development teams should also request support from the leadership team in offering additional educational resources and training.

    Breaking down the silos between development, quality, security and operations to create a true DevSecOps culture will take adjusting on all sides, and it all starts with people. Highlighting the benefit of working together (increased security, streamlined processes and ultimately a better product) is the best motivator.

    — Pete Chestna

  • DevOps Brings Value to Security (and Vice Versa)

    DevOps Brings Value to Security (and Vice Versa)

    Many enterprises today are implementing security solutions that can be deployed and maintained more quickly and easily, and at lower cost, using a DevOps methodology.

    Organizations applying DevOps to security are not looking at IT groups separately as the database team and the application team; rather they see everything as the delivery team. It’s also a team that works together that deliver security services for customers.

    Application, database, network and endpoint security have traditionally been segregated, and you can see how that is built into the tools. DevOps is about bringing these pieces together and integrating operations because it’s about implementing security starting at the top of the value chain—the customers. Ultimately, we look at the value we’re delivering for the customers with security and really making sure we are inserting it into the front of the pipeline. Leading DevOps shops integrate security upfront when building the next big product, feature or service for external or internal users.

    Related Content:

    DevSecOps: Putting Database Sec In DevOps

    DevOps Introduces Complexity. Really

    There are several different models of organizational structure used to insert security into the software development life cycle. Most make sure it is an integral part of everything that gets released. But the point is that it needs to be integrated. It needs to be a living part of everything an organization is doing.

    One effective choice is make sure DevOps engineers are focused on the standardization of the network and the application.

    For example, look at locks. Most of the time, developers are keeping all passwords in locks. As a DevOps team, we’re sharing locks. That means that all credentials, even credit card information, can be exposed. Before we release the features, we need to think about security and remove passwords and credit card details.
    [su_pullquote align=”right”]Security needs to be a living part of everything an organization is doing.[/su_pullquote]
    When we look at the network and the database side, we need to disable all ports, and this is important to do before releasing things. Disable all the network ports and bring all the databases into these, and open only relevant ports.

    If you are going to embed security, it’s actually cheaper, more efficient and faster to do it in the DevOps team; otherwise, you have to train engineers in application, database or network teams on security or add an expert into those teams. But, if you add the security expert into the DevOps team, you could involve fewer people or simply additional people who are cross-trained.

    When we talk about cost savings and cost reduction with our clients, we focus on two things. We look at the model that shows how the cost of finding defects goes up as the product is developed. If you can include quality from the beginning, you reduce cost of maintenance and cost of quality—that’s the first thing. The same is absolutely true of security—that’s the second thing.

    When you’ve got an integrated SRE full-stack engineer working hand in hand with the development team, they’re thinking security, operational agility and maintainability of the system from the get-go, and they’re inserting those non-functional requirements and making sure they’re adhered to across the stack.

    This method is not at the exclusion of having the application team run code tools on security on their applications. Rather, it is someone who is looking at all these pieces and making sure they’re being done correctly.

    Ultimately, we’re producing a product that is not only functional, but actually operable in an efficient and effective way. It can’t break every minute, causing us to spend millions just to keep the darn thing alive. It works the same way with security.

    Even if it’s operable, if we get hacked, the company has a massive data breach liability.

    By having skilled engineers on the front line—particularly skilled DevOps engineers on the front line—you’ve got folks who are thinking in that full-stack mode about the security implications of the system’s operation and any issues they may see, making them more able to identify things that are potential threats.

    — Sean Mack

  • DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    In this DevOps/Security Boulevard Chat we speak with Rohit Sethi, COO of Security Compass about ASRTM, which stands for Application Security Requirements and Threat Management. Gartner has recently released a hype cycle on ASRTM, with Security Compass and its SD Elements offering named a leader in the market. Rohit gives us a good background and foundation on ASRTM and why it is important for both DevOps and security teams.

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

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 119457″ target=”blank” width=”200″ height=”200″]Rohit Sethi
    Rohit Sethi joined Security Compass as the second full-time employee. As COO, Rohit is responsible for setting and achieving corporate objectives, company alignment and driving strategy to execution. Previous to this role, he managed the SD Elements team. Rohit specializes in building security into software, working with several large companies in different organizations. Rohit has appeared as a security expert on television outlets as such as Bloomberg, CNBC, FoxNews, and several others. He has also spoken at numerous industry conferences s and/or written articles on major websites such as CNN.com, the Huffington Post and InfoQ.[/su_pullquote]

    Alan Shimel: Hey, everyone. This is Alan Shimel for Security Boulevard Security Chat, and this will also be appearing on devopsy.kinsta.cloud under DevOps Chat. So two chats for the price of one, though it’s one chat. Welcome, and we have a great guest lined up for today. I have Rohit Sethi—and I mispronounced that. I think it’s actually Rohit Sethi. But in any event, you can correct me. Rohit, welcome.

    Rohit Sethi: Thank you.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    DevOps Chat: Aqua Security Seeks To Secure Containers

     

    Shimel: Just for the record, say your name correctly.

    Sethi: Rohit Sethi.

    Shimel: Rohit? Okay. Rohit, you know, as my mom used to say, “Call me anything you want, but not late for dinner.”

    Sethi: [Laughter]

    Shimel: Welcome to Security Boulevard Security Chat and thanks for joining us. So you are the COO of Security Compass, correct?

    Sethi: Correct.

    Shimel: And there’s probably people in our audience who maybe are not familiar with Security Compass. So why don’t we start there. Can you give us a little bit of background on Security Compass?

    Sethi: Sure. We are a firm that is specializing on software security. And we have three main offerings around that. So we have an advisory practice that does penetration testing, and code reviews, and threat modeling, but also helping people build up their secure software program. And especially more recently building up their dev sec ops program and building security into their DevOps pipeline.

    Shimel: Mm-hmm.

    Sethi: We have a training practice, which is specialized in training developers. We’ve partnered with ISC-Squared and we offer a certificate or batch program on secure development for software developers. And then we have a product called SD Elements, which is an application security requirements and threat management. I know that’s a mouthful. And what we’re going to talk about today is a platform that helps people build security and compliance to some extent into their software development process, and particularly for agile and dev ops processes.

    Shimel: Excellent. Now, so a couple of things that we want to talk about relate. And one of them is recently Gartner’s come out with another magic quadrant or a new magic quadrant where they’re kind of lumping together what I personally always thought of was two distinct areas. And they’re calling it – and I’m going to mess this up. Why don’t you help me? AR –

    Sethi: ASRTM.

    Shimel: ASRTM. Why don’t you tell our audience what that stands for?

    Sethi: Yeah. ASRTM is application security requirements and threat management. And it’s not quite a magic quadrant yet, but it’s on the hype cycle.

    Shimel: Hype cycle. You’re right.

    Sethi: Okay. So they’re identifying it as a sort of an emerging category for people to start paying attention to.

    Shimel: Yep. And so for our audience and for me, talk to me. How did the nexus here between them?

    Sethi: eah. So you can think of [Laughter] anything in this category as being tooling that helps you to build security into the onset of development. Most of the tools that exist in the application security category today are some form of static analysis, dynamic analysis, interactive application, security testing. So really all different kinds of testing looking for security defects, or blocking the tax in real time. Right? So real-time application security protection or web application firewalls.

    And many people their entire budget is on testing and sort of blocking attacks. But really very little focus on building security from the start, except for perhaps in training. So everything in this tool category is essentially some kind of product that will help you to systematically and in kind of a scalable way build security in so that you don’t get those defects when you do your testing. And perhaps more importantly, to prevent defects that perhaps those automated tools are just incapable of finding.

    Shimel: Got it. Got it. Got it. Got it. And so I think we’ve laid the foundation, if you will, Rohit. Let’s jump into a little bit of how this relates to dev ops and what we call dev sec ops. So why –

    Sethi: Yeah.

    Shimel: Go ahead. Why don’t you take a lead on that?

    Sethi: Yeah. For sure. So DevOps is a phenomenon that it’s not just for sort of fast-moving organizations. Even some of the slower or I guess you’d say larger companies are starting to embrace DevOps, as you know. And it’s becoming really quickly sort of a mainstream philosophy. And there’s just really rapid pace of change of tooling that people are looking at – and not just tooling, but processes, to be able to accommodate continuous integration and continuous delivery in all of the mentality changes and processes that have to change to allow that to happen.

    Now, when we think about the traditional secure software development life cycle, there’s a lot of activities that we’ve typically suggested in the security community about following a secure SDLC, that really kind of incongruent with this idea of either having really fast sprints or no sprint, no iterations, just being able to take one ticket at a time, build it, and deploy it. So the idea of doing like an architectural analysis, or a one-week or two-weeks threat model, these things are sort of thrown out the door when the pace of development is too fast to keep up with it.

    And so that kind of opens up the need for automation. Now, there’s sort of a trend, and I would call it, I would label it a dangerous trend, that people are looking to 100 percent automated solutions to sort of take away the security problem. Right? So you’ll see sometimes people will put together presentations on DevSecOps and they’ll say static analysis is sort of your way to handle secure coding. And then perhaps some penetration testing on a periodic basis and you’ve kind of checked off the box for secure development. But the reality is that, in fact, security is a lot more complex than that.

    Static analysis tools and dynamic analysis tools have their strengths, but they also have significant gaps. We actually put together a white paper that talks about the missing parts of what scanners can’t find, false negative gap. And one of the interesting things is if you look at sort of CC plus plus development for a second, one of the most pervasive vulnerabilities is buffer overflows. This is the thing that caused Heartbleed and WannaCry and pet. Yeah. It’s sort of the underlying root cause there was some memory management issue.

    And if you were to take some of the best practice in terms of highly automated scanning solutions and put them all together, they’d still be able to find less than half of all buffer overflow vulnerabilities. Yet, this is what a lot of the industry is converging on as good enough from a software security perspective.

    So not everybody looks at it that way, and there’s a lot of people who realize that there’s a gap here that we need to do more than just scanning. It is an essential part of the solution, but we need to be able to identify what are all of the relevant threats to an application development, and how do we actually build mitigating controls rather than fixing the vulnerability after the fact? So prevention instead of detection.

    And that’s really where the ASRTM category fits in. It allows you to define what those controls are and build them into the software development process. Not only, in fact, from a security perspective, but also like compliance control, some of the GDPR issues that will come up there.

    You have to kind of build data protection by design and default. You need a system, a systematic way to identify these as essentially requirements that go into your backlog, right, and that you can track whether or not they’ve been tested. And that’s quite different than the approach that people have typically taken to finding vulnerabilities after the fact and fixing them.

    Shimel: Mm-hmm. So Rohit, our audience, especially from devopsy.kinsta.cloud, of course, is extremely savvy to the whole DevOps and DevSecOps terminology and kind of what’s happening. One of the issues that we see with this, though, is so many of our security solutions are geared for security professionals.

    Sethi: Yeah.

    Shimel: Where so much of the real responsibility for secure coding and secure apps lies with the developers.

    Sethi: Yes.

    Shimel: Right?

    Sethi: Yeah.

    Shimel: And to that no one – you know what? I’ve never met a developer, Rohit, who raises his hand and says, “I want to develop insecure code.” Or, “I want to have an insecure application.” They all want security, obviously.

    Sethi: Yeah.

    Shimel: But they may not have the expertise. They may not have the support. They may not have the time, frankly, to do it right.

    Sethi: Yeah.

    Shimel: So how does like a Security Compass type of solution help not only the security guy, but the developer, as well?

    Sethi: Yeah. Excellent question. So the way that the work flow in an ASRTM solution works – and I’ll talk specifically to ST Elements, which is our product. But we’re not the only product that does this. Is that somebody in a product team – so we have a lot of clients that use it this way. It’s sort of a self-service model.

    So let’s say like a project manager. And so you mentioned developer, but I would extend that to the entire development team, right? Product owners, product managers, scrum masters, etc., right, who are involved with building software. So you take sort of a lead, whether that’s product manager, project manager, product owner, scrum master, lead developer. And they fill out a questionnaire that’s kind of like a base online ramp up of that software they’re building. So they’ll answer like a multiple-choice questionnaire.

    And then based on the results of that questionnaire, they’ll get a defined set of prescriptive controls that are essentially security user stories, right, that you need to build into your software. And then what they’ll do is they’ll integrate it into gira, or Microsoft Team Foundation server, or whatever it is that the development team is using to manage their backlog. And then the product owner is then responsible for grooming it, just like they do feature or functional stories. Right?

    So now what we’re doing is we’re taking the backlog, which is sort of the de facto list of work that needs to be done, and we’re putting non-functional requirements alongside the functional requirements, which allows the development team to take control of when they’re going to implement security work or security features, as opposed to just reacting to a security defect that’s found later on. So basically you’re turning unplanned work into planned work. So that’s the first thing that you do to sort of empower the development team.

    The other, of course, is that when you take a look at these requirements and these controls, you actually start to bake training into it. So someone might get a control that talks about how to implement a secure password reset. Right? So this is a feature in the system that is the kind of thing that you really can’t find with an automated scanner, but that could lead to significant risk if it’s done incorrectly.

    So you can actually have a Gira ticket that talks about the correct way to implement secure password reset, and you can have an actual embedded training module so somebody could actually learn about well what are the ways that people exploit password reset at the time that they implement the control. So it’s what we call just-in-time training. We think it’s a really important and powerful concept, especially as it relates to fast-moving development.

    Shimel: Absolutely. So Rohit, I’ve always wanted to ask this question, then. And that is it’s incredibly difficult, then, as a Security Compass, let’s say –

    Sethi: Yeah.

    Shimel: To, I mean, number one as a salesperson to, who do I sell to? Who has the budget? Who is my technical stakeholder?

    Sethi: Yeah.

    Shimel: Who is making decisions? But beyond, you know, pity, no one’s going to play hard to the flowers for the sales team. [Laughter] But beyond that, as a solutions provider, serving two masters here.

    Sethi: Yes. Yes.

    Shimel: How?

    Sethi: You know it – go ahead. Sorry.

    Shimel: No, no. I was going to say how does that – I just, it’s gotta be really hard.

    Sethi: It is hard. I wouldn’t say that it’s easy at all. But I think that it’s critical work. Like our vision as a company is a world where you can trust technology. And we really think that if we don’t do security right, that that vision will not be realized. People will be afraid of technology to some extent. We won’t be able to exploit the possibilities that technology affords us because we’re afraid of vulnerable technology.

    And really, when you think about the root cause of most of the security incidents, sometimes it’s an insecure web application, but sometimes it’s a vulnerability in your desktop or operating system, or like a browser component or something. But so often it’s a secure coding issue. And so much of the sort of cybersecurity budget and infrastructure is based on the fact that well, let’s just take for granted that the software is insecure, and let’s find ways to mitigate the risk.

    And of course we’ll never get 100 percent secure code. But we really think that there’s a huge gap between what we can feasibly do, right, versus what’s being done in industry today. And so that motivates us. And I think often when we start to talk about the data, we talk about and when we’re talking to the chief information and security officer, or the chief information officer, we talk about a visibility gap that they have, right?

    Which is that right now the way that most companies work is they have a GRC solutions and sort of a policy departments to talk about what their high-level information security policy is. And then they may have some automated solutions to help enable that policy. But there’s sort of a gap between this high-level policy and then what are the specific things that an IT team needs to do to make sure that that policy is being followed and being able to track that?

    And that’s really, I think, at the heart of what an ASRTM solution provides is the ability to take this policy, turn it into procedure, turn it into something you can track, and ensure consistency, right? Because you can’t rely 100 percent on sort of automated scanners to catch everything. So you need to have this sort of translation there. And we find that that works pretty well. People are receptive to that need.

    And then, in fact, it’s not just application security, but it also involves infrastructure security, hardening servers, and that sort of thing, bender security, bender risk management, cloud security, how secure your cloud applications, and how do you know what to test against? So just like a variety of needs are met by adopting a program, really, that allows you to define your security controls at the granular level that your DevOps teams can implement them and you can track that.

    Shimel: Fair. Fair enough. So what does the future hold here, then?

    Sethi: Well, my hope is that we realize that vision, right? We get to a point – what I would like to see, for me success in the long term is that when we find that there’s a vulnerability that’s exploited in the wild that that vulnerability never creeps into code again. Right? Like if we know how to mitigate it, then it’s mitigated forever. And we’re so far away from that reality right now. Right? Like a lot of the real-world exploits are traced down to what is the root cause? It’s a secure coding issue that we’ve known for 15 or 20 years, in some cases.

    And that’s just not good enough. So we’d like to get to a place where the only hacks that occur are really novel. Right? Like we’ve never seen anything like this before. And some really profound security researcher has found a security issue that they’ve spent a significant amount of time understanding that specific domain. Right? But not sequel injection. Right? Not parameter manipulation. Not things that we’ve known for years. And that’s really, I think, where we want to go. And I think that inevitably that’s the direction that the industry is going to move towards.

    Shimel: Agree. Agree. Rohit, when we started, I told you the time goes quick. And we are coming up on our 15-minute window. But let me give the listeners – we want to find out more about Security Compass. Where can they find out more?

    Sethi: Well, of course, you have, you know, SecurityCompass.com talks quite a bit about what our offerings are. You can feel free to e-mail us, info@SecurityCompass.com. I’m personally on Twitter so you can follow me. Just @RKSETHI. We have a LinkedIn page for Security Compass, as well. So lots of different ways you can interact with us.

    And like I said, we offer training. So a lot of people who are, just want to learn more about application security, we have courses that you can just sort of enroll yourself. And we’ll be releasing more of those in the near-term future, as well.

    Shimel: Got it. All right. So Rohit Sethi, thanks very much for being our guest on this episode of Security Boulevard Security Chat, as well as DevOps Chat. And we look forward to hearing more about Security Compass in the coming months. Thanks for being our guest today.

    Sethi: Thank you for the opportunity. Appreciate it.

    Shimel: All righty. Rohit Sethi, Security Compass here on Security Boulevard. This is Alan Shimel, and we’ll see you soon on another DevOps or Security Boulevard Chat.

    — Alan Shimel

  • How Developers Can Take a More Proactive Approach to Security

    How Developers Can Take a More Proactive Approach to Security

    Developers tend to get thrown under the bus when it comes to application security, but recent data shows that developers do, in fact, care about security. Take mitigation for example. Developers don’t try to rig the system by rejecting findings as false positives or as mitigated by design. Developers documented mitigations for just 14.4 percent of all flaws found by CA Veracode’s platform in the past year.

    Still, IT and development professionals shouldn’t wait for a major breach to occur to uplevel their security skills. Here are a few ways developers can shift their approach from reactive to proactive.

    Seek Out Alternative Education Options

    The education path for IT and development professionals has some serious holes, especially when it comes to security. A whopping 76 percent of IT leaders report that they weren’t required to take a single security course in college. Many technology professionals are entering the workforce without a cybersecurity education, thus requiring them to learn their most crucial skills on the job rather than in the classroom.

    Across industries, online learning has emerged as one of the most valuable resources for working professionals who want to learn new skills. Online education is flexible, personalized and covers a wide array of subjects. The impact is clear: Simply by completing basic online learning courses about common vulnerabilities can help a developer improve their fix rate by an average 19.4 percent.

    Related Content:

    Cloud Services Demand Security Up the DevOps Stack

    CA Technologies Survey Uncovers DevSecOps Challenges

    Many times, developers are forced to take education into their own hands. Sixty-eight percent of IT decision makers report that their organizations don’t provide adequate security training, so they must find a way to fight for educational resources. Teaming up with security colleagues to make the case to the C-suite is one way to do this. A two-pronged approach could make a difference when asking for increased training budgets.

    Be Aware of Open Source and Component Risk

    The industry is facing a dilemma in securing the software supply chain. As development processes become increasingly automated, a lot depends on how well development teams can piece together open source components with their own handwritten code. This practice increases efficiency and lowers technical debt, but opens new doors for hackers.

    Open source components usually carry their own set of vulnerabilities and risks. In the past year, the majority (87.6 percent) of Java applications scanned by CA Veracode suffered from at least one component-based vulnerability. Many organizations either aren’t aware of these vulnerabilities or don’t even know what components make up their software products.

    Beyond lack of awareness, consistency in patching is also a problem. Once a development team integrates open source components into their code, they rarely update when security patches are released. Attackers frequently jump on newly disclosed vulnerabilities to target victims that fail to update fast enough, so thorough patching is crucial.

    Simply put, teams must bring a better discipline to the use of code components. Finding new ways to monitor, track and manage open source components in code is one of the most impactful activities developers can participate in to ensure secure software.

    Leverage Security Teams as Consultants

    As DevOps practices spread and more organizations require developers to do their own security testing, the role of the security team is evolving. Security professionals are becoming more like consultants that can uplevel developers’ skills with advice on best practices, strategic planning and individual coaching. This is where the idea of DevSecOps comes into play.

    To bridge the gap between development and security teams, attitudes need to adjust on both sides. Security teams must begin approaching developers with an attitude of enablement and developers must be willing to team up with colleagues that have a hacker mindset and expertise in understanding threats to the organization.

    Developers who see security experts as a resource rather than an opponent can make significant improvements to the security of their software application portfolios. Developers who paired their vulnerability findings with remediation coaching from security experts saw an 87.6 percent better fix rate than those who received no coaching.

    When it comes down to it, both security and development teams should try to be more proactive. If both sides commit to breaking down silos and learning from each other, they will find that DevSecOps is the best way to ship software both quickly and securely.

    — Pete Chestna

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • Barracuda Networks Advances DevSecOps Agenda

    Barracuda Networks Advances DevSecOps Agenda

    Thanks to the rise of DevOps, a fundamental shift is now underway in terms of the amount of influence developers exercise across the enterprise. Rather than simply dumping code on IT operations teams, developers increasingly are being held accountable for applications end to end. As such, developers now often exercise a lot more influence over which software-defined infrastructure and security platforms will be employed as part of what is referred to as the “shift to the left.” These platforms all have in common a well-defined set of application programming interfaces (APIs) that makes them accessible to developers.

    Against that backdrop, Barracuda Networks announced its Barracuda NextGen Firewall can be configured via the IT automation framework developed by Puppet Labs. Previously, only the company’s Web Application Firewall was integrated with the Puppet framework.

    In addition, the Barracuda NextGen Firewall is now available as a metered billing service in the Amazon Web Services (AWS) Marketplace. That marks the company’s second metered billing service on AWS, after making a similar move with the Barracuda Web Application Firewall last year.

    Tim Jefferson, vice president of public cloud, says an increased focus on application security is driving an expansion of DevOps processes to now include DevSecOps driven by APIs rather than traditional user interfaces, which are not well-received.

    Jefferson says those REST APIs are critical for any security company that wants to stay relevant as organizations start to manage multiple development pipelines that are tied into a common continuous integration/continuous development (CI/CD) pipeline. In that context, Jefferson says it’s no longer sufficient for IT security companies to make their offerings available as a virtual appliance. Security tools such as firewalls need to be just another cloud-native application that can be orchestrated as part of a CI/CD process, he says.

    What’s more, DevOps teams have made it clear they want to be able to consume anything deployed on a public cloud in the same manner they consume compute and storage resources. That requirement is driving companies such as Barracuda Networks to add a metered billing option because many organizations in the age of the cloud don’t want to pay for a firewall unless it’s actually in use, says Jefferson.

    It’s too early to say precisely how DevOps and DevSecOps are transforming the way IT products and services are acquired and invoked. In the case of Barracuda Networks, for example, the company is taking the rise of DevOps as opportunity to expand its portfolio of products first to include data protection by acquiring Intronis and then, more recently, compliance and archiving tools by acquiring Sonian.

    Naturally, not every IT organization is equally far down the DevOps and DevSecOps path. But the various walls that have isolated various segments of IT are finally starting to come down at an increasingly rapid pace across the enterprise.

    — Mike Vizard