devopsy.kinsta.cloud

Tag: application security

  • DevOps Security Champion: Who, What and Why?

    DevOps Security Champion: Who, What and Why?

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

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

    Security Champions in DevOps

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

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

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

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

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

    Enabling Security Champions in DevOps

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

    1. Identifying Teams

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

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

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

    2. Role Distinction of Team

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

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

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

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

    3. Select Champions

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

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

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

    4. Stay Connected and Communicate Clearly

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

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

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

    Conclusion

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

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

    — Zehra Ali

  • DevOps and Security: Be Ready to Shield Your Application

    DevOps and Security: Be Ready to Shield Your Application

    All of us have heard of continuous improvement/continuous delivery (CI/CD). There are many benefits to implementing CI/CD, as it helps seamless integration from end to end for development and deployment processes. CI/CD helps in rapid improvement, shorter release cycles and more, but it also helps with the challenge of handling security effectively at DevOps speed.

    Tools for Securing DevOps

    There are thousands of DevOps security tools available in the market that help us at HCL Technologies secure our software development at various stages of the CI/CD pipeline. There are new vulnerabilities rolling out daily, and so we must be alert and keep our applications safe and future-ready.

    These are the DevOps security tools we use (most tools are open source with an option of enterprise edition):

    1. OWASP SonarQube
    2. OWASP ZAP
    3. OWASP Dependency-Check
    4. OWASP Glue
    5. Anchore
    6. Clair-CoreOS
    7. FOSSA
    8. Cyberark Conjur

    Our DevOps Toolchain Diagram

    Securing CI/CD

    Let’s consider a job in which we check out the code from GitLab/GitHub with auto-commit (a Jenkins job will be triggered as soon as the developer makes any changes in the code). You can refer to this link for  more information about Jenkins GitLab automation.

    Now, in Jenkins, we can run a security test and present it in the form of reports and dashboard to meet our needs. To get started, we can use OWASP SonarQube for static analysis. OWASP SonarQube includes found bugs, PMD and several security plugins bundled out of the box. Next, for dynamic analysis and penetration testing, we can use OWASP ZAP, which presents reports in XML/HTML format that can be used to create Jira issues.

    In the above scenario, we can also use ZAP through custom tools integration. In our case, we have installed ZAP on our local machine. We can also use OWASP ZAP installed in a remote machine.

    Steps for Remote OWASP ZAP Connection

    Windows Command: C:Program FilesOWASPZed Attack Proxy>zap.bat -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    Linux Command: Zed Attack Proxy>zap.sh -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    OWASP Configuration in Jenkins

    The reports will be generated in .xml and .html format. Now, with the reports generated by ZAP, we developed a Java program to create Jira issues for every vulnerability detected and assign it to the concerned person.

    Next, we have OWASP Dependency-Check analysis on our project. To configure for Jenkins, follow these steps:

    First, we need the OWASP dependency-check plug-in (which I have already installed). This process may take several minutes, as it downloads from NVD server.

    Here are the next steps:

    Alternatively, we can use the OWASP Glue plug-in, which runs OWASP ZAP, OWASP Dependency-Check and other security automated tests.

    We have also used FOSSA in our projects for license audits and vulnerability management for OS dependencies. We can use FOSSA as on-premises, but it is available only for use on Ubuntu machines.

    At HCL, we are currently working on container security with Anchore and Clair-CoreOS. We have also integrated identity access management (IAM) to our CI/CD jobs. As for IAM, we are working on CyberArk Conjur and HashiCorp Vault.

    CyberArk Conjur

    The Conjur Jenkins credentials plug-in:

    HashiCorp Vault

    Conclusion

    I have worked on various tools for security with DevOps. Below is a quick comparison of the tools that can be used for application security.

    Now that you have an idea of which tools to use, embrace security instead of worrying about it. DevSecOps can help improve and increase the outcome and effectiveness of any organization.

    — Debarghya Pandit

  • 5 Practical Ways to Deliver Secure Software That Could Actually Work

    5 Practical Ways to Deliver Secure Software That Could Actually Work

    Almost every aspect of modern life is dependent on technology. As technology becomes even more advanced and pervasive, so, too, does the need for secure software.

    Today, even the tiniest breach at an organization could result in major loss of sensitive data. Therefore, it is crucial for both the reputation and proper functioning of the organization to have steady security measures in place.

    Below are five practical ways organizations can deliver secure software by prioritizing safety and maintaining a sustainable “security culture.”

    Organizations Build and Foster a Healthy Security Culture

    A security culture, just like any other culture, thrives when it is used actively. Effective security culture is a one-time investment that can reap major benefits. However, it requires effort from the organization.

    A viable security culture is based on four key features:

    • The security culture is disruptive in nature and brings about immediate change.
    • Security practices employed by the organization are engaging for everyone, not just the security department.
    • A proper reward system is in place for the people who actively take part in security regimens.
    • Investments made into the security culture are returned in one form or another.

    Ensuring that a proper security culture is in place takes care of the biggest problem in the development of software—humans.

    The establishment of a robust security culture helps humans in an organization more than it does the computers. It provides a proper framework through which employees at an organization can act to maximize security.

    Some ways to develop the security culture at an organization include:

    • Instill the belief into the employees that security-related issues are not just the headache of the security department; rather, the whole organization should work together to resolve them.
    • Focus on spreading awareness throughout the organization by providing employees the basic security knowledge.
    • Provide opportunities for advancements in security to team members who are more excited.

    Despite having a strong security culture in place, however, breaches may happen. A proper security culture can help the organization recover more swiftly.

    Acquire a Secure Developmental Life Cycle

    A secure developmental life cycle (SDL) provides a firm foundation to monitor the security practices in an organization.

    An SDL performs essential functions such as threat modeling, security analysis and requirements, and carries out security testing. The organization that acquires the SDL agrees to an in-depth study of their security on all the software and system releases.

    Microsoft, for example, offers a free SDL that consists of security practices that could help organizations regardless of their size or platform. This is especially useful to those organizations that have just started.

    Other benefits of having an SDL are:

    • Detects bugs in the software earlier in the development cycle, which is cost-effective.
    • Safeguards the interests of the stakeholders and investors, as it makes the business secure.

    Overall, an SDL minimizes the risks that an organization faces and helps in advancing it.

    Integrate Security Tests Into the Developmental Phase

    Organizations should introduce security tests in the developmental period; that is, when the code is being written or when the programmers check in on their codes.

    The introduction of security tests allows developers to correct their mistakes at an early stage, which effectively reduces the cost of resolving the problem. Developers actively get feedback, enabling them to design software with a smaller number of flaws.

    Moreover, tests conducted at the developmental stage save time and keep the disruption caused by the whole developmental process to a minimum.

    Have a Deep Understanding of What’s in Your Software

    Developers should work with security experts to understand the software and the applications installed.

    Knowing what constitutes applications—especially open source applications—is pivotal in patching any discrepancies that may arise.

    Along with a firm grasp on the software, developers must be aware of application security.

    Application security, or AppSec, teaches advanced lessons to the testers and developers within an organization and aids them in building secure products and services.

    Encourage Mentorship

    No security system is complete without a set of security experts who can train developers in specific methods and procedures. These mentors can be responsible for conducting security tests and furthering the advancement of secure software in an organization.

    Mentors can also provide a learning experience to the staff members and go the extra mile to make sure security is accessible for everyone.

    Conclusion

    Organizations need to maintain a standardized way of delivering software. The threats we face today, if  not dealt with, can have dire consequences.

    However, the solution starts at the very beginning and needs to be integrated into everything related to software, from education to the way employees interact with each other in the workplace. Only then can we rest easy knowing our software and data are protected.

    — Zehra Ali

  • 4 Steps to Improving Your Team’s Continuous Security

    4 Steps to Improving Your Team’s Continuous Security

    A recent npm survey revealed that 77 percent of developers were concerned about the quality and security of the open source libraries they use, while 52 percent said the tools currently available were inadequate. Given the trust issues in open source and the ongoing discovery of website and application vulnerabilities, security should be top of mind for developers at the start of every project—but also on an ongoing basis. I call this practice of constant re-assessment “continuous security.” Here’s how I like to describe it:

    Imagine you are standing at the bottom of an escalator that’s moving downward. Your goal is to reach the top. You might think, “Easy, I’ll just sprint my way to the top! Run as fast as possible and I’ll get there, and the problem is solved.”

    It’s not that easy, though. As you start your climb, you realize that you haven’t really trained for this and you’re slower than expected. The people traveling down toward you become obstacles to be evaded. Through all this, you have to maintain your upward momentum, or you’ll end up back where you started.

    Now, it might sound a little cliché, but that’s how I view security. Security is something you have to continually train for—a constant cycle of risk discovery, prioritization and skill-building to close the gap to get results.

    Continuous security is all about becoming more efficient at this entire life cycle and reducing the time to risk discovery and the overall cost of mitigation.

    Risk Discovery

    The first step to improving your security situation is to find something that needs improvement. These tend to be risks to the business and look different depending on your focus area. For a legal team, that might be license compliance; for a development team, it’s likely to be a security bug in a production service.

    When you start out, your abilities to discover risk are going to be pretty poor, but that’s okay. I like to apply this discovery process at the natural gates of the development life cycle. Major ones include: when the feature is designed, when code is first written and when someone makes a pull request, pushes code to staging and pushes it to production. The tooling and techniques you use in each of these stages will vary greatly by the needs of the business and change as your security program matures. There will be arguments continually about what is considered a risk and how it should be prioritized. This is part of the process of refining your risk discovery skills and tools.

    Policy and Standards

    There is rarely any change without pressure, and because we don’t always have an active incident to force improvement, that pressure sometimes has to come from within. Motivating your team through policies and standards can be the ideal way to influence improvement.

    Everyone in your organization will have their own perspective, so developing a strong set of policies and standards to measure yourself against will go a long way. Writing and adopting these standards should be collaborative, both with your security team and the organization as a whole.

    These policies help you determine what is a risk and how you prioritize it as an organization. At npm we have a standard rating scale that security assigns to risk (P0 = drop everything and fix critical, to P3 = fix within 180 days). This tells engineering how long each risk should take to mitigate, helping them prioritize their work accordingly.

    Mitigation and Improvement

    This is where the technical practitioner will have the most fun—fixing lapses in security is usually satisfying work. The important part is to use each incident as an opportunity to scale your efforts in risk identification.

    For development teams, that means pushing more automation in your CI/CD pipeline to arm developers to be able to find security issues earlier in the development process. I like to call this the CI/CD/CS pipeline: continuous integration, delivery and security. However, automation is far from perfect, and the best way to improve decision-making is to provide a human with the right amount of information in the right context whenever a decision needs to be made.

    An important thing to remember is that your solution does not have to be perfect. There are many situations in security where “better” is good enough to mitigate risk to an acceptable level. In the end, what you need to have is a constant feedback loop of risk discovery and mitigation, using technology and processes to manage and improve.

    Continuously Improving Continuous Security

    Setting goals and expectations is a part of continuous security, but you should keep in mind that “security” is not a set destination. The word “security” lies to us by suggesting that it’s possible to secure something, when in truth the mitigation of all risk is an impossibility.

    Instead, always try to maintain your upward momentum. Measuring all successes and failures honestly allows you to be effective at all times, whether in the middle of a security issue or a period of relative calm. A continuous, proactive approach to security is the only way to effectively ensure the safety of developers and code.

    — Adam Baldwin

  • API Security: A Key Part of the Bigger Plan

    API Security: A Key Part of the Bigger Plan

    Standing as the “fuel” powering the customer-driven platform revolution, application programming interfaces (APIs) are the new “it thing” amongst operating systems.

    APIs are responsible for how apps communicate with each other and have become key components in many digital transformation strategies. Serving as a set of tools for building software application, they have empowered many businesses to increase their value. However, as they have risen in popularity, concerns have risen over the adequacy of measures being put in place to ensure security for businesses using APIs.

    The Open Web Application Security Project (OWASP) is a global non-profit organization committed to improving application security and makes it a primary mission to ensure software security is a priority for all. OWASP regularly issues a top 10 standard set of rules that are applied to security policies across various platforms. The most recent list presents notable changes that reflect the increase in dependency on APIs, with a focus on how they can both help and hinder security efforts.

    Why Should Businesses Care About API Security?

    Every application needs APIs. It is difficult to find an organization today that doesn’t have its own app or uses an app to complete critical business activities. They contain programming standards, instructions and protocols that allow applications to communicate with one another. Essentially, APIs serve as a bridge that ensures proper and consistent communication between two systems.

    API security is a critical part of API development because millions of applications communicate back and forth daily. With the cyberthreat landscape constantly evolving and the cloud API market predicted to experience a 20 percent CAGR by 2022, it is easy to understand why it is so imperative that companies develop and continually implement thorough API security measures.

    Most APIs do have some governance from management tools, which can offer a range of control features aimed at making APIs more reliable, secure and controllable. However, security should also be top of demand in the design phase of an API and formulating controls that can be implemented across the organization.

    Arming Your Organization with the Right Security Tools

    Systems that host public APIs feel the impact of heavy traffic on a daily. Some of that influx is, unfortunately, not authentic. To avoid overburdening the legitimate users and protect their system, companies need to evaluate behavior to flag potential problematic traffic.

    API security works in the same manner by using rules and algorithms that evaluate client sessions. APIs ask simple questions that gauge how clients are behaving, what they are doing and whether there are unusual error rates or repetitive behavior in short time periods.

    Machine learning is often used to answer these questions and to identify and deter malicious API client practices. Standard web approaches typically don’t function properly with APIs, simply because hackers work to continuously be ahead of the game. They know that standard DoS attacks don’t work, so they distribute hacking attempts across bots that hide alongside legitimate traffic to sneak them through the system, undetected.

    To find these bad eggs and stay on top of the large amount of them, it’s necessary to set up a machine learning-based system that have a deep understanding of API traffic, with a thorough understanding of API keys, access tokens and what the typical request context is on any payload.

    How Can You Prevent Attacks Right Now?

    There are several actions you can take immediately to protect your system from potentially damaging attacks. Begin by using HTTPS, if you’re not already, to ensure proper authentication and authorization. Also, adjust your software development life cycle (SDLC) to include rigorous API security testing and validation with a primary focus on input validation.

    Also important: Make sure all network servers are running on regularly patched OS versions that are stable and include carefully configured security groups. Implementing role-based access control and VPC isolation across environments also can help improve responses to prevent attacks.

    Finally, having a pre-documented response policy for security incidents will help your company establish a secure development environment that is properly maintained at all times.

    Routine API audits and testing can help your organization continually improve the API development and ensure your business is protected against DDoS attacks and malicious bots, while still letting legitimate API traffic through. These techniques will help you validate API requests and sort through which are legitimate and which are not, to completely eliminate or reduce API attacks.

    — Eltjo Hofstee

  • DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

    DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

    I have known of Jeff Williams in the security industry for more than several years. He is a well-respected thought leader in AppSec and OWASP. I finally got a chance to catch up with Jeff and talk with him about Contrast Security, the company he co-founded and how it is helping.

    In this DevOps Chat, Jeff and I discuss the state of application security and how AppSec fits into the larger DevOps realm. Jeff’s a great interview with lots to share.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat has a decidedly security bent. I’m happy to be joined by Jeff Williams, CTO and co-founder of Contrast Security. Jeff, welcome to DevOps Chat.

    Jeff Williams: Thanks, Alan. Good to be here.

    Shimel: Hey, my pleasure. So, Jeff, you know, as we were talking off mic, this is the first time we’re kinda interviewing anyone at Contrast. Why don’t we—I think it’s only fair we start off with sort of, let’s give our audience a little background. Who and what is Contrast Security?

    Williams: Sure. So, I mean, you know that many enterprises struggle with application security. You know, there’s been an application security industry for like 20 years. I helped to start OWASP back in the early 2000s and I wrote the OWASP Top Ten, and organizations are still struggling with the same problems.

    So, Contrast targets exactly those problems. We are kind of a radically different approach to doing application security. We’re very compatible with DevOps kinds of processes. And basically, we find vulnerabilities so you can shift left in the development and fix them. We analyze open source code, so you can make sure you’ve got safe versions of the components you’re using, and we protect applications in production. And we do it all through dynamic binary instrumentation. So, very much like a New Relic or an AppDynamics, but for security, not performance.

    Shimel: Security prudent security monitoring—excellent. And Jeff, you mentioned, though I don’t know if we’ve spoken like this before, but I’m certainly aware of you for a long time within the security community. This isn’t your first rodeo. [Laughter] You were instrumental in OWASP. You know, we’ve seen application security not—it’s evolved, yes, but it’s still, at the end of the day, it’s about the application, right?

    But yet, you know—look, it used to be, application security meant some kind of app firewall, which—

    Williams: Yeah.

    Shimel: – I’m not saying a WAF isn’t a great tool, it is. It’s changed the game in a lot of ways, I think, in what—

    Williams: Not really. [Laughter] I don’t think so.

    Shimel: Well, it’s made a lot of people a lot of money and it’s taken a lot of venture capital, let’s put it that way, right?

    Williams: Well, that’s not my measure of success. [Laughter]

    Shimel: Yeah. But has it made us safer?

    Williams: Not really, no. No.

    Shimel: But one can argue we’ve done a lot of things and not a lot of them have made us safer, right?

    Williams: That’s right.

    Shimel: You and I have both been in security for 15, 20–plus years, Jeff. And the latest buzzword is DevSecOps, and being that I’ve transitioned to DevOps five, six years ago, and I run devopsy.kinsta.cloud and I’m involved in Security Boulevard, I’m all about DevSecOps, and I’m not here to say it’s snake oil or bull or anything like that. But as we were talking about, it means a lot of different things to a lot of different people.

    Williams: That’s right, that’s right.

    Shimel: Why [Cross talk], what do you think it means?

    Williams: Well, you know, to me, DevSecOps is a way of viewing security the way that folks viewed software development through a DevOps lens.

    Let me back up. So, software had a ton of problems 15, 10, 20—I was a developer for a long time back in the early ‘90s and so on. And, you know, software development back then had tons of problems. It was late, it was very error prone, long feedback cycles, slow release times. I worked on one government program for three years, and it never was fielded. [Laughter]

    Shimel: Mm-hmm.

    Williams: So, that kinda thing plagued software. But, I think, DevOps has really revolutionized that, you know, basically just focusing on getting work flowing, creating short feedback loops and creating a culture of innovation of learning. Like, those things transformed the way that software is produced. I love the factory analogies and all that.

    Now, if you look at security, we have exactly the same problems. Security doesn’t really deliver a tangible result. Like, you never know when you’re done. So, the work isn’t defined. That means the work isn’t flowing. You know, we have these tremendously long feedback loops. I did a bunch of work for a major financial institution. They were on a system where some apps got a one year pen test, some apps got a two year pen test, and some apps got a triannual pen test. So, every three years, they would take a look at security. It’s crazy.

    And, you know, so we need to make tighter feedback loops, and security has this culture problem. It’s not a culture of innovation and learning, it’s a culture of enforcing rules and compliance and gates and guards and bottlenecks. And that all can change. If we apply the lessons of DevOps to the problem of creating security in an enterprise, we can define the work, we can create shorter feedback loops, and we can create a culture of innovation and learning. That’s really the challenge. In my opinion, that’s why security continues to struggle is, it’s just not delivering what we want it to deliver.

    Shimel: Yeah. You know, and—look, truth be told, Jeff, that’s what attracted me to DevOps. I thought it was an opportunity for us to kinda reshape the playing board and maybe change the rules and finally deliver—nothing’s perfect, and I don’t think anything is, I’ve seen enough so-called silver bullets to know none of them—

    Williams: Sure.

    Shimel: – [Cross talk] full of crap. But I thought, at least, it shifted the game pieces in such a way that we could, it was a more even playing field, or a better situational playing field for us.

    Williams: Yeah. Done right, I think DevOps can have a tremendously transformative effect on organizations building software. I’ve seen it in a bunch of large enterprises and small companies, you know, and we’re a DevOps shop here at Contrast as well. You know, we’re deploying six, seven times a day, and I have a huge amount of confidence that that makes us deliver much better software.

    And so, my challenge—

    Shimel: Much better software, or much—but is it also more secure? Because shouldn’t that be—I mean, that’s something I strive for, right?

    Williams: Right.

    Shimel: That security becomes synonymous with quality.

    Williams: Yeah. That’s right, that’s exactly right.

    Shimel: Is it more secure?

    Williams: Absolutely, it’s more secure. But you do need some better tools. So, I think, you know, to do security in a DevOps way, you need accurate, real time feedback on the code that you’re building. If you don’t have that, then you have to have experts involved. So, there’s a fundamental relationship. If your tools are producing inaccurate results, then you have to have experts to dig in and resolve the false positives and find the false negatives and, you know, it’s a ton of human expert work.

    That’s not compatible with DevOps. So, you need these accurate tools in order to give real time feedback right to developers. But that’s where instrumentation comes in. If you can get inside the code that you want to test for security or protect against attacks, that’s where all the context is. That’s where the information is. And so, using all that information, you can make really accurate decisions about whether something’s a real, exploitable vulnerability, or whether something’s a real, viable attack. And then you can give that instant feedback, you can create tight feedback loops, and you can deliver security.

    And I’ve seen it work. Companies have transformed themselves from the way they used to be with a big backlog of security vulnerabilities, they’re running scans every six weeks or six months or whatever. They’re piling up vulnerabilities, they’re not really fixing anything, and that’s a very unhealthy way to be. They transformed from there into an organization where they’ve worked off the backlog and now they’re in what I call the new normal. They’re just dealing with new vulnerabilities as they come in, as part of the normal workflow. And it’s massively more cost effective, because they save all that downstream work of tracking and classifying and risk creating and all this stuff. You know, it’s super expensive and doesn’t produce anybody any value.

    Shimel: Yeah. I mean, just, even from the security guy’s point of view to work in that scenario where I don’t have that technical debt, if you wanna call it that—

    Williams: It is—security debt.

    Shimel: Security debt. That’s a great word for it, right? Without that hanging over my head, how much easier and better is my life? And it’s so true. And the other thing, Jeff, is—honestly, until you’re at that point, I don’t think you can talk about automation and velocity and speeding up this whole thing, because when you’ve got all that dreck hanging in your background, you know, you can’t do it, right? You can’t—

    Williams: Well, that’s right. Traditional security is very destructive to modern software development. If you have to involve those bottlenecks and get experts involved, I’ve seen it just wreck DevOps—you know, organizations are trying to do DevOps, but they’re hamstrung by their legacy security teams and processes and technologies. And I wish it wasn’t that way, because security has potential to be a great force for innovation.

    Shimel: Yeah.

    Williams: If you can give people a fantastically secure platform, they can roll out awesome applications and awesome functionality at super high speed. Do things that normally you wouldn’t think you could do, but if you have the platform, you can really make crazy things secure.

    Shimel: Absolutely.

    Williams: It’s just—

    Shimel: I mean, and, you know, I was talking to my friends, John Willis and Damon Edward, they’ve both presented at Dozen, and the notion is, you can have it all. You can have faster applications, better, more secure applications, higher quality—all three, right? You could have two out of three ________, you could have all three doing DevOps and DevSecOps if you’re doing it right.

    But here’s another thing I want to touch on, Jeff, and that is, I don’t know whether it’s shiny trinket syndrome or single-mindedness or we can’t multitask, but just because someone says DevSecOps can do, can make your life better, can do all of the things that you and I are talking about doesn’t mean that we throw everything we learned about security out the door, right?

    Williams: No, no—of course not.

    Shimel: Well, for too many people, they’re like, “Hey, we don’t—okay, man. You know what? Screw that AppSec stuff, we’re just shifting left,” even though shifting left is, you know, fundamentally AppSec. “We’re just shifting left and we don’t have to worry about all of these other CIA things that we learned about, right, traditionally in security.”

    I don’t think anyone’s saying one necessarily replaces the other, or that it—

    Williams: No, I think really it’s more about being extremely clear about the outcomes that you want to achieve with security, and then putting in place a highly tuned machine that can produce those results continuously and repeatedly over the course of a project. Shifting left is a weird term, to me.

    I love the idea of doing security earlier in the process, but many people see that and say, “Oh, well, developers just do security now,” and they wash their hands of kinda the old ways of doing things. And unfortunately, that’s a recipe for disaster. I think you need to empower those developers with technologies that can let them do their coding and not introduce security vulnerabilities.

    And it’s not just about shifting left, because in QA and in staging and CI/CD environments, you want to verify that everything is secure before you push to production. So, you’re really not losing that step. You need to do both, shift left and where it is now. And frankly, I think a lot of organizations should also consider shifting right and doing more protection in production. Because so many organizations that I talk to—I was just talking to a massive technology company here on the West Coast this morning—they’re really pretty blind about what’s going on at the application layer from a security perspective.

    So, to me, it’s not really about shifting left, it’s actually about extending left and extending right and using a DevOps process to produce the outcomes that you really want.

    Shimel: Yeah. I don’t disagree there. The reason I brought it up, though, is, you know, we could point fingers all around, but sometimes the security industry is its own worst enemy, and the cynics and the cynical within—well, we’re consuming ourselves with other stuff right now, but the cynics and the cynical folks would then say, “Oh, it’s just another buzz word, and it’s just something meant to take your eye off the ball, and we have got to hold this thing in our cold, dead hands and not let go.”

    Williams: Yeah, yeah. It’s a fair point. I mean, DevSecOps is a little buzzwordy, and frankly, I’m sympathetic to the folks that say, “No, it’s just DevOps, and security is a part of it, of course.”

    Shimel: Now, that’s my—so, that’s where I am.

    Williams: Here’s how I think about it, though. Let me try and change your thinking about it—it is just DevOps, but there’s a view of the DevOps process that emphasizes the security pieces. It’s very much like a blueprint for your house. You know, you’ve got the elevations, then you turn the page and it’s got the plumbing plant, and then you turn another page and it’s got the electrical plant and so on.

    It’s a little bit like that, for me. DevSecOps is the security view of DevOps. It just emphasizes the security aspects of the DevOps process so that you can see what’s going on and actually understand it in a little different way than if you were just viewing the whole thing all mashed together. It doesn’t really help to just smash it all together and call it all quality. So, that’s how I think about it, it’s just a view of the normal DevOps process.

    Shimel: I don’t necessarily disagree. I think there’s only one DevOps, but I think—I know, I mean, so this year, at RSA, for instance, for the fifth year on the Monday of RSA week at the Moscone Center, we’re gonna be putting on DevOps Connect: DevSecOps Days. And over the course of the five years, we’ve called it DevSecOps, we’ve called it Rugged DevOps.

    Williams: Yeah.

    Shimel: Just don’t call us late for dinner.

    Williams: [Laughter]

    Shimel: And it’s kind of the security community that has driven the DevSecOps name, because they wanna make security is kinda in the middle, I guess. But—hey, whatever. If that’s what it takes to get people on board and doing things to make this more secure, so much the better.

    Jeff, we started talking and I wanted to talk more about Contrast, though. Share with our audience—so, you guys are involved in AppSec, you’ve got a bunch of things going on. Any new news, anything, you know, we are coming into RSA season, everyone always has some sort of news around that. Anything you can share or talk about?

    Williams: Well, I think the big thing for us this year is launching what we call run time exploit prevention, which is sort of our next generation attack detection. And the reason that it’s, I think, so compelling is because it leverages our deep experience in instrumenting applications at run time.

    And so, instead of just trying to block attacks by looking at HTTP traffic and saying, “Oh, well, that’s got a SQL injection in it” or, “That’s got an XXE in it or something.” Instead, we’re instrumented deep within the code, and using that position, we can access a lot more contextual information. We can make really smart decisions about what an attack really is.

    And this is interesting—we’re essentially defusing all forms of SQL injection and deserialization problems and XXE and expression language injection and so on by sandboxing powerful components inside the platforms.

    So, I can give you an example. All these struts and spring vulnerabilities from over the last year and a half or so? They all involve sending untrusted data to an expression language and evaluation engine. So, what Contrast does is, we sandbox those evaluation engines to prevent dangerous stuff from happening while they’re being executed. So, you know, when you’re evaluating an expression, you don’t expect to be starting native processes and accessing files and opening socket connections and stuff like that. So, we prevent all those things from happening during expression language evaluation and restrict the program to only evaluating a normal expression.

    It’s a very powerful technique for ruling out not just known vulnerabilities like in struts and spring, but we’re ruling out all forms of expression language injection, even ones that nobody’s discovered yet. So, I think that’s very exciting and puts you in a really unique position for dealing with new CVEs that are coming out every week.

    Shimel: Yep. Absolutely, and that’s huge. I mean, in spite of everything and in spite of the cynicism, the pessimism, and everything else, it actually is an exciting time to be in development and security, right? We are—

    Williams: I love it. [Laughter]

    Shimel: Yeah. You know, we’re making progress where good things are happening in spite of, you know, every day we still hear about another breach or another, you know, incident.

    Williams: Well, I’ll say this—I think it’s time that every application has the ability to detect if someone’s attacking it, and respond appropriately.

    So, forever, we’ve—basically, our policy around AppSec has been, “Well, let’s build a wall around it to try to keep out the bad stuff, and then let’s scan it to see if we can find where any holes are.” And both of those approaches, I think, have sort of gotten less and less useful over the last seven or eight years, to the point where, today, they’re not really very helpful, particularly on modern applications that are built using APIs, they’re deploying containers in cloud and they move around and all sorts of things. Those approaches just don’t work any more.

    So, fundamentally, building that protection into the applications itself is very compelling to me. It works at scale, it’s accurate, it’s very fast, it’s much faster than building barriers around stuff. And so, there’s just a number of advantages, and I’ve seen it transform organizations from the kind of organization we were talking about before with the huge security backlog, security debt. And they’ve, over the course of a year or a year and a half, they’ve transformed themselves across thousands of applications, to the point where they’re just dealing with the new stuff coming in. They’re in that new normal.

    Shimel: Yep, absolutely. Alright, man. Hey, Jeff, we are—we’re well over our 15 minutes.

    Williams: [Laughter] Awesome.

    Shimel: Yeah, so, we’re gonna have to call it a break on this one. But you know what? Between now and RSA, maybe we can get you back on here, we can talk a little bit more about this. It’s a hot topic, it’s—

    Williams: One quick point, if you want to try Contrast or expose yourself to IAST and RASP, you can use Contrast community edition for free. It’s fully powered, free for one app, and you can just sign up and start using it today.

    Shimel: Where do you get it?

    Williams: It’s at ContrastSecurity.com/ce.

    Shimel: CE. Alright, excellent. Hey, Jeff Williams, CTO of Contrast Security, thanks for being our guest on this episode of DevOps Chat. Until next time, everyone, this is Alan Shimel, have a great day, for devopsy.kinsta.cloud, DevOps Chat, and Security Boulevard—take care, everyone.

    — Alan Shimel

  • Security Testing: Reducing Resistance to Change in an Agile and DevOps World

    Security Testing: Reducing Resistance to Change in an Agile and DevOps World

    Software development has evolved, but security testing has not. That has to change

    In the bad, old days—which, sadly, many are still living in—security testing was tacked onto the end of the development process. Security testing hasn’t been a feature of software engineering for around 15 years now, since agile supplanted waterfall as the primary development methodology. The old idea of security testing as an independent, external audit, where security folks sit far outside the development process, is ineffective at preventing massive data breaches and ensuring developers have the knowledge required to build secure applications.

    Until the mid-1970s, the concept of desk-checking software was necessary due to the slow turnaround time of punch cards, compilation and batch job testing. Desk-checking and formal verification are the genesis of the security audit. Though software engineering has developed through timesharing, real-time debugging, individual computers for each developer, waterfall, object-oriented programming, rapid application development and, finally, agile and DevOps, security is still stuck in the mid-1970s. Security professionals are not auditors and security audits are not a viable replacement for sound security engineering.

    There is no doubting the need for objective tests along the way, but the construction industry shows us the way here. Any large building project regularly tests random concrete deliveries for compression and tensile strength. While every metaphor breaks down if you push it too far, there is a place for continuous security testing in an agile world. This should take the form of executable tests, rather than reports.

    Modern “unicorn” development is proud of the DevOps culture that allows developers to push code into production many times a day. But in the DevOps deployment model, it’s impossible for traditional security practices to keep up. A typical security testing schedule is every 12 to 18 months if you’re lucky, or never if the app is not considered significant. There could be thousands of untested builds in that time.

    How do we fix this? How do we scale? The security profession must adopt agile and DevOps processes and use the same tools as developers. It is that simple. However, it’s incredibly difficult for many. Historically, security professionals haven’t come from a development background, and so the concept of delivering security tests as source code is at odds with 40 years of penetration testing.

    The first thing that must change is the way organizations receive results. One of the tenets of an early agile methodology called “extreme programming” (XP) is “you ain’t gonna need it” (YAGNI). I posit you “ain’t gonna need” a PDF report. Results should be delivered via APIs, directly into existing development defect trackers, such as Jira or GitHub Issues, or a vulnerability management solution. The worst possible outcome is a 60-page PDF sitting unread in someone’s inbox—or worse, trying to scrape it or manually cut and paste into an Excel spreadsheet. Developers will never see the entire report, as if it is a state secret, and yet they have to fix discovered issues.

    I hear screams in the distance! How’s an internal audit going to verify that security is in place and effective without a PDF report? They can and should look at the results of builds. It is that simple. If developers can demonstrate that every build for the last 12 months passed security unit and security tests, that is a job well-done. No one asks accountants to provide a PDF report of the latest reconciliation as proof that reconciliation is working. The evidence is that the numbers are the same in the online accounting and banking systems. If an auditor wants to produce a cover sheet saying that they randomly sampled build testing results over the last 12 months and assert that the results are a true and correct representation of security effectiveness, good for them.

    Security professionals are not auditors and should not be writing reports. They should be testing software, sharing knowledge and writing tests. Security professionals should be embedded with developers, helping them understand why a security test has failed and discussing solutions, possibly even coding a potential solution. Security professionals can learn about the enterprise and specific application business risks, and the development team can learn how to fix current issues and protect against security failures in the future.

    It’s critical to understand that as executives ponder this change, there will be resistance. The security industry is structured around delivering short-duration, high-skill testing. This type of testing often tests the skill of the assessor and web application firewalls, and not the application itself. Modern security practices—such as the one I lead—have moved to abuse cases, where no web application firewall will protect you. We have offerings and talk with our clients about agile CI/CD pipeline security, but even though what we want to move on to will be utterly obvious to everyone in a year or two, resistance is strong.

    How do you move forward in the interim? Ask your security vendors to deliver proof-of-concept unit or integration security test cases to be run in the build pipeline. Provide source code to your apps so they can write the tests in the same codebase to test every build and allow your developers to maintain these tests.

    In the meantime, review the effectiveness of your PDF-based security program. Challenge your vendors to come up with something that works with your development teams rather than treating them as adversaries.

    — Andrew van der Stock

  • Always-on Development: Why Continuous Delivery Relies on Security by Design

    Always-on Development: Why Continuous Delivery Relies on Security by Design

    How continuous delivery can help organizations in their application security efforts

    The old model of developing secure applications followed a structured, siloed, step-by-step process—build, check, release. Organizations’ desire for speed has forced development teams to ramp up their release cycles by any means necessary, even if it means bypassing incremental scanning for flaws that could increase application risk. This philosophy of rapid innovation also comes with increased risk exposure. 

    Security and development teams need to find ways to keep up with the rapid development life cycle without sacrificing security with every update. The continuous delivery model has transformed application development, but to last, it must also transform application security. It may take a little extra time and effort, but it is possible to develop efficiently and securely.

    Continuous Communication

    The key is to make sure that security and developer teams understand each other’s priorities and needs. As DevOps began to catch on, the immediate reaction for many organizations was to make their developer team into a jack-of-all-trades unit. This began by adding operationalization to the developer job description and has only grown from there. Soon after, security, testing and monitoring functions joined the list as well. Recruiting teams are now struggling to find people who are qualified for this multifaceted role.

    Teams operating on a continuous delivery model need to find a middle ground between the developer solely focused on coding versus owning every step in the development process. Developers should be at the center of everything—keeping the priorities of each role in mind and making sure each is involved in the final product, but focusing on their main job of development.

    This philosophy goes both ways. Security teams and other specialties can always learn more about the intricacies of the development process, which will enable them to better integrate their functions into a continuous delivery cycle without disrupting it.

    Continuous Improvement

    One way to encourage a unified team, specifically in regards to security, is to appoint a security champion for each development team. These advocates should be developers who have a special interest in or affinity for security. Their role is not necessarily to know how to solve every application security problem that arises in the development process, but to ask the right questions about security and interface with security teams.

    Roles such as this create firms links between the different functions of DevSecOps practices, making it easier to realize opportunities for improvement under the new continuous release model.

    One small change that can make a big impact is realigning review processes for continuous delivery by reviewing only the pieces that have changed instead of the whole application. Under traditional, linear development cycles, each new release requires a full assessment even if much of the code remains unchanged from previous versions. Applying the continuous delivery mentality to security testing can streamline and reduce the burden on security teams. Each new piece of code deployed in continuous release models is faster to scan, which makes flaws easier to find and fix. 

    The assembly line model of application development is no longer feasible. If security teams wait for the application to be complete before fixing vulnerabilities, they will never be able to keep up with the pace innovation and competition demands. Making the most of continuous delivery requires constant communication and collaboration across the full DevSecOps spectrum, along with a shift in thinking that allows developer and security teams to use the process to their advantage.

    — Mark Curphey

  • DevOps Chat: A New Take on Application Security with Portshift

    DevOps Chat: A New Take on Application Security with Portshift

    Portshift brings a new identity-based application security model from code to runtime. Cloud or on-prem, Portshift works. In this DevOps Chat we speak with CEO Ran Ilany and VP Business Ops Eran Grabiner about what is unique to the Portshift solution and why you should consider it for your own application security, especially for your DevOps teams.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and you’re listening to another DevOps Chat. In today’s DevOps Chat, we actually have a new company to introduce to our audience anyway and that company is Portshift. And I’m joined by two of the key folks at Portshift. We have Eran Grabiner, who’s VP of Business Ops, and Ran Ilany or Ilani – I mispronounce your name, I apologize – Ran Ilany, CEO and –

    Ran Ilany: Ilany.

    Shimel: Ilany, great. CEO and cofounder. Gentlemen, welcome.

    Ilany: Thank you.

    Eran Grabiner: Thank you, Alan. Thank you for having us.

    Shimel: Oh, my pleasure. So, Ran, you’re the CEO. I’m gonna let you kick off. A lot of people in our audience may not be familiar with Portshift. Fundamentally, what’s Portshift about?

    Ilany: So, fundamentally, Portshift is trying to solve – solving a problem which is a hard problem that wasn’t solved in the last couple of decades and was very much introduced as a solution, during early ’90s, with the firewalls technology. And now we’re moving to the cloud infrastructure, we see that the same firewalls that were used 20 years ago are not longer, I would say, valid, in order to run a application. And, essentially, there are, I would say, two to three reason that to that and I will let Eran elaborate about the reason of why.

    Grabiner: Yeah. Sure, so, you know, Alan, when speaking about the cloud, there are two things that fundamentally changed everything for IT folks and DevOps engineers. The first thing: you don’t own the infrastructure, so the level of network and infrastructure, you simply don’t control it.

    And, secondly, a lot of change through time in the world of compute. If – I don’t know – ten years ago, we had the monolithic application sit down in our data centers in the office, right now, when we’re in the cloud, our application is broken into many different pieces, many different _____ services. Everything is much more automated. Software is being updated on an hourly basis. And developers and engineers, they have much more power to do things with their software. So, because those two reasons that the old tools that we had, in order to orchestrate security in our network, simply doesn’t work.

    Ilany: Yeah, and –

    Shimel: Agreed. Ran?

    Ilany: And just to add to those points, there are two layers that essentially impose the challenge. The first one is the fact that, if you’d really like to, I mean, to use firewalls within the cloud environment, you really need to understand the network infrastructure. To understand the network infrastructure, you need to understand what is the application is doing out there in the cloud, and, in order to do this, you need to configure those IPs and those ports, which actually create a very, very close binding to the actual network infrastructure, for one hand.

    And, for the other hand, you obviously need to have this type of discussion between the security folks to the actual operation folks, which actually creates a lot of bureaucracy that was possibly valid, you know, 15 years ago in the data center, but, now we’re moving to the cloud and everything is automated with CI/CD, you need something else. Okay? You need to break the paradigm, at least from being tied to the actual network, from one hand, and, from the other hand, you need to make things to be much more fast and much more intertwined with the development life cycle. Which is essentially the primary objective that Portshift’s have put in as a target and as a solution.

    Shimel: Absolutely. So, guys – and, look, I’ve been in this a while myself. You know, when we first started with the next-gen firewall, right, and that was sort of the premise, is that we were gonna get the developers involved and application-aware firewalls and all that, but it didn’t translate to the cloud. You’re right. But, Ran, I’m interested, as the CEO/cofounder, so this is obviously a problem, right? How do we do this in a cloud environment, at cloud scale, at cloud speed and all of that?

    Ilany: Yeah.

    Shimel: How did this affect you personally or in your kind of journey to where you’ve got here today, where you recognized and said, “Hey, we gotta do something about this, that this is a problem looking for a solution here”?

    Ilany: Yeah. So, essentially, we understand that there is a problem that requires a solution, you know, while talking with customers. I mean, those are usually the No. 1 –

    Shimel: That’s the way –

    Ilany: Yeah, and –

    Shimel: – the best way to do it.

    Ilany: And we saw that there are – and we call it “the impossible tradeoff,” okay? They either need to be very, very fast – they want to run very, very fast in the cloud, from one hand, but then they have a security constraint. They really want to control, I mean, the communication between the application and where the application should run. And there, there is the where to be in the curve of being Agile and being secure every organization has to find itself, in this type of curve, and to find what is the level of security that it wants to enforce or impose.

    And this is, I would say, what led us to think of changing the paradigm or breaking the paradigm or making a solution that the customer will not have to make this type of tradeoff or make this type of decision and target to be both fast and Agile but also secure from the other way around _____ _____.

    Grabiner: And we basically looked at what’s going on in the cloud from the DevOps perspective and we saw that many things changed to be better, with automation, with CI/CD tools, and we ask ourselves why, with security, this is not happening? Why the workstation or the tools that the DevOps engineer is now using to deploy software, why security tools can’t look the same? Why they can’t be part of the same idea and the same work cycles? And this is what got us to think that we need to, in a sense, push security to the left, shift left, and take it to be something that is part of the DevOps life cycle and part of the CI/CD infrastructure of the organization.

    Shimel: Sure. So, guys, obviously – so we call this “DevSecOps,” right? Is part of it.

    Grabiner: Yeah, right. Yeah.

    Shimel: It’s something that I – you know, between DevSecOps Days and events we put on at RSA and so forth, it’s something we’re very involved in. My question for you then is, so it sounds like Portshift is really aimed at helping DevOps engineers, DevOps teams, developers, get more involved in the security or in the cloud firewall kind of paradigm for security. Is Portshift aimed then at the security team, the developer team, or both?

    Ilany: So I think – well, obviously, the focus of Portshift is not to try to educate Dev and DevOps to be security folks – this is obviously not the target – but think the good news is the fact that Dev and DevOps have the knowledge, okay? And the knowledge is where, essentially, they know their intention. They know where, essentially, they want to deploy the application and, essentially, who should talk to who, in terms of application containers or processors, depending, obviously, on your infrastructure. And this is, I would say, the basic assumption that the whole concept of Portshift is based on, okay? We actually take this type of knowledge, okay? We create from this knowledge or this attributes, we create the actual identity of the application, which is essentially a signed infrastructure or crypto-signature of those attributes. And we use those intentions that are described by DevOps, in their own natural language – I mean, a recipe in Cookbooks with, you know, _____

    Shimel: A Chef or a Puppet.

    Ilany: Yeah, of course. Or Ansible or Kubernetes, obviously, infrastructure. We use this type of information while creating the crypto-identity, in order to deploy those application or signed application in the cloud and enforce the actual security that we describe formally. And the whole point is, essentially, that those folks don’t have to change the way that they work, okay? The security is more intertwined with their own system, the CI/CD system.

    We leverage this type of information in order to create the security and the actual security folks will actually define guardrails. Okay? They will define operational environment in high level – the production environment, the testing environment, or the preproduction environment – where the actual application should run within. And the security will be sort of enforced and be visible automatically, without the pingpong, okay, or without the never-ending discussion between the security and the DevOps folks, which we all know it’s part of the problem, okay? It’s part of the challenge of securing the application in the cloud prams.

    Shimel: Absolutely. So I guess this – well, let me back up a sec. I just wanna make sure. Portshift, I know you work with AWS, obviously.

    Ilany: Mm-hmm.

    Shimel: Microsoft Azure, Google Cloud as well?

    Grabiner: Yeah.

    Ilany: Mm-hmm.

    Grabiner: We’re totally agnostic to the infrastructure.

    Shimel: Okay. And what – I’m curious ’cause this is something that we going back and forth on, back and forth on. The attitude of the developers, the DevOps teams. I mean, you never meet a developer who says, “Oh, I’d wanna make an insecure application or I want my stuff to be hacked,” right?

    Grabiner: No.

    Ilany: Mm-hmm.

    Shimel: And you’re right – they’re not security people, but they’re security-aware and they need to be security-responsible.

    Ilany: Mm-hmm.

    Shimel: Right? On the other hand, look, we all know security people who’ve said, “The developers will do what I tell them,” right? “And they’ll be secure when I tell them they’re secure.” But that doesn’t work either in this new world. Right? It’s gotta be together. So you talk about integrating with the CI/CD process. Give us an idea of how you work within the CI/CD process.

    Grabiner: Got it. Yeah, so, basically, what we’re doing, we are asking the developers, the DevOps engineers, to use a very simple set of APIs, whenever they are using their infrastructure as a code or whatever the tools that they’re using, to send Portshift the relevant information that we need, in order to identify the piece of application that they’re deploying. This information can be technical information about the build, the version, the namespace of the application, and other attributes, that will allow us to rip up an identity that is unique, for each and every one of the pieces of the application. So this is the first part, where we learn your application logic, where we understand who should speak with who, and we know your business.

    Now, when we take this identity and we move into runtime, we see all the different pieces and, first of all, we see them for sure. We know because we find them during CI/CD. If something didn’t go through CI/CD, if a developer deployed a container without asking, if, god forbid, an attacker is moving in the network, we would immediately see that because we signed the components during CI/CD. And we can see them. We can see them communicate. And now security folks and also DevOps engineers, they can easily define their agenda and their rules, based on their application logic.

    A simple example: if they want their billing app to speak with their financial database, something that can take days just to config because your application is broken into different pieces and you need to config security groups and make sure you did it right and so on, with Portshift, you would simply write this sentence. You would just say, in English, “I want my billing application to speak with financial database,” and that’s it. Everything will work from then on.

    Shimel: So it sounds magical, right?

    Grabiner: Yeah.

    Shimel: You know, I’m too old to believe in magic. What’s going on behind the scenes, though? When I write that, what’s actually happening behind the scenes?

    Ilany: Yeah. So, essentially, what happens behind the scenes is we have two phases for this identity bit generation. As eloquently mentioned by Eran, the first phase is done by offline, okay? We take this type of attributes, which are sort of the intention, okay, in the CI/CD. We grab those as attributes of the identity and this is essentially the description of the application – wherever the application should run, who should it talk to within the actual environment that we’re targeting to.

    And then we have the correlation with the runtime properties. Every process, every containers have runtime characteristics – for instance, the process ID, the UID, memory footprint, and stuff like that – so we combine all together the offline attribute that was created with the ICD, with runtime attribute. We sign them all together.

    And this essentially creates one unique entity that is running out there and this is what we’re using in order to enforce. We are transferring this type of identity in the traffic stream so that a conversation between two different application is, first and foremost, authenticated, okay, and only then authorized. Okay? This is what we call the classical “zero-trust” approach, okay? We’re not trusting the IP; we’re trusting the identity on the counterpart.

    And this brings another where we talked, I believe, a little bit about the operational benefits and the fact that it’s very Agile and useful for the Dev and DevOps and the security collaboration. But there is another very important advantage and it’s the fact that, now that we are not talking about an attack surface which are segments, network segments, we are talking about type of access. Okay? So, if an attacker, for instance, get into one of my workloads or one of my application, we are not losing the whole segment, okay? We are losing a single part.

    And now we have, I would say, less – we’re much less concerned from the extent that we are exposed, okay, because we are talking about only point-to-point access permitted. They’re not network segments, which are open and, from the attacker perspective, it’s like a dream come true. If I find a flat network and I get into your flat network in some miraculous way, then I can get into every resource or application that is out there.

    Shimel: A good target.

    Ilany: Yeah. And this is, essentially, the basic concept of the security perspective of identity-based access control between different applications.

    Shimel: Sure. Guys, it sounds fascinating. As I mentioned to you when we started, the time goes very quickly. We’re kind of at the end of our time.

    Grabiner: Yeah.

    Shimel: I apologize, but maybe we can continue the conversation. For people who are interested, Portshift, you can get more information at portshift.io. Correct?

    Ilany: Right.

    Grabiner: That is correct.

    Shimel: And you guys will be at AWS Reinvent, though –

    Grabiner: Correct.

    Shimel: – _____ _____ after. Will you be at RSA conference?

    Grabiner: Yes. We will also be presenting there, at a startup venue.

    Shimel: Oh, the Launchpad or the Sandbox?

    Grabiner: The – I think it’s called – I think it’s the Launchpad. Yeah, it’s where all the early-stage companies are. Yeah.

    Shimel: Yep. Sandbox – that might be the Innovation Sandbox. Launchpad is more for ideas.

    Grabiner: Oh, yeah.

    Shimel: I think you fit more in – yeah, we’re a big part of RSA, so, yeah, I just did a podcast with them about both of those, so little bit I know. Anyway – I’m sorry. Thank you very much for joining us and we will – if we don’t see you at AWS, we’ll see you then at RSA. Well, we’d like to probably hear more because this kinda fits right into our sweet spot. Ran, Eran, thank you for joining us on DevOps Chat today. Good luck with Portshift. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • You Have a Box: The Impact of Containers on DevOps

    You Have a Box: The Impact of Containers on DevOps

    To continue the discussion from my last blog post, you have a box. Increasingly, you only have to ask, “What do we want to put in it?”

    It is interesting to see the growth and change in IT over time. The advent of containers is the focus of this particular blog, but there are many other topics that would be fun to cover in the same manner.

    The fact is that containers have become our blank puzzle pieces. We take it, make it what we need and drop it in. They relieve us (for the most part) of the need to worry about deployment issues and allow us to focus on getting the part of the app they represent right.

    But those deployment issues didn’t go away, they’re simply obfuscated. Networking, security, storage and even capacity still have to be concerns of IT, just not concerns of a given app or its developers. That creates a separated world of issues, sometimes a split world of issues—such as networking inside/outside the container environment—but these are largely things we’ve had to deal with since the advent of virtualization, just in a larger scope.

    The true promise of multi-cloud comes with containers, also. Each cloud vendor wants to lock users into their container architecture, of course, but nothing stops a shop from running containers and container management on cloud instances of their own, maintaining the highest level of portability for the cost of some extra management headaches. In the end, where it is running is even less important in the container world, and that allows what it does to gain more importance.

    Management of containers has a bit more overhead; after all, hardware or cloud management needs are the same, and the configuration/management of containers is layered over those needs as an additive. But that’s a worthwhile cost to bear if the result is that tomorrow the container could be thrown to a cloud instance, and the next day for whatever reason—capex versus opex, data accessibility, whatever—could be brought to a local server. Maximum flexibility makes the cost of maintaining another layer of management.

    And much of that layer of management can (and usually is, in my experience) be folded into DevOps practices, precisely because a container is 100 percent software. That means the overhead is not nearly as large as it seems. And what isn’t well-covered by DevOps is simply an extension of virtualization.

    So with containers, you have a box. The management of the box is handled by DevOps. The only question that really matters is, “What are you going to put in the box?” And that’s pretty cool: Less to worry about during development means more time to make whatever goes in the box rock.

    And the innovation around those boxes is just getting geared up, I think. We already see things such as shops/projects with a container life expectancy of less than a minute that are inconceivable in other environments. Not that they’re all good ideas, but the more people doing things in a different manner, the more opportunities for really great discoveries to come along.

    And you will be there. Filling boxes with cool new apps. Pretty sweet.

    — Don Macvittie