Tag: devsecops

  • 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

  • 9 Pillars of Continuous Security Best Practices

    9 Pillars of Continuous Security Best Practices

    Without proper consideration given to security best practices, the continuous delivery of software changes facilitated by DevOps is risky. On the other hand, DevOps provides an opportunity to reduce security risks if security is integrated into the continuous delivery pipeline according to best practices.

    This blog enumerates best practices for security across nine pillars of DevOps: Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Continuous Monitoring, Elastic Infrastructure, Continuous Delivery/Deployment and Continuous Security. Examples of best practices for each pillar are listed. These practices can be used to assess an organization’s maturity within the journey to Continuous Security, often referred to as DevSecOps.

    Leadership

    Leaders need to understand and sponsor a clear vision for security.

    • Leadership demonstrates a vision for organizational direction, team direction and three-year horizon including security practices.
    • Leaders intellectually stimulate the team status quo by encouraging asking new questions and question the basic assumptions about the work including security practices.
    • Leaders promote personal recognition by commending teams for better-than-average work, acknowledging improvements in the quality of work and personally compliment individuals’ outstanding work including security practices.

    Collaborative Culture

    Culture in organizations that work well with DevOps have a collaborative continuous security mindset.

    • The culture encourages cross-functional collaboration, shared responsibilities and avoids silos between developers, operations, project management, quality assurance and security.
    • The DevOps system (toolchain) is created by an expert team and reviewed by a coalition of stakeholders including security.
    • Changes to end-to-end DevOps workflows are led by an expert team and reviewed by a coalition of stakeholders including security.
    • DevOps culture empowers and trains team members to take personal responsibility for security, compliance and privacy obligations.
    • Security engineers/architects are involved in the design for modular components, and also consulted when security patterns change within modules.

    Design for DevOps

    Designing software for DevOps at speed requires application designers to master the best practices for continuous security.

    • Software source code changes are pre-checked with static analysis tools, prior to commit to the integration branch. This assures that the modified source code does not introduce critical software faults and security vulnerabilities such as memory leaks, uninitialized variables, array-boundary problems and SQL injection.
    • Software component analysis scans third-party components for known security vulnerabilities and identifies risk during the build process.
    • Security frameworks for technology stacks that are used (such as Apache Shiro or Spring Security) are documented and shared with developers for their respective technology stacks.
    • Software code changes peer code reviews include checks for defensive coding and security vulnerabilities prior to committing code to the integration/trunk branch.
    • Common security components such as identity, authorization, key management, audit/log, cryptography, protocols, etc. are maintained, published, readily available and used within module development.

    Continuous Integration

    Continuous integration (CI) within organizations that have multiple teams working concurrently on a project and different code bases is challenging. During the integration stage it is critical to assess the application and understand the impact of code changes from a security point of view.

    • A software version management system is used to manage versions of all changes to source code, executable images and tools used to create and test the software.
    • Incremental static analysis pre-commit and commit checks are wired into CI to catch common mistakes and anti-patterns quickly by only scanning the code that was changed. These checks identify security vulnerabilities through control flow and data flow analysis, pattern analysis and other techniques. These techniques find security-related issues such as mistakes in using crypto functions, configuration errors and potential injection vulnerabilities.
    • Binary artifacts are digitally signed and stored in secure repositories.
    • Changes to security patterns used within software source such as session management, authentication, authorization and encryption code trigger a notification or pull request to security engineers.

    Continuous Testing

    Continuous testing (CT) with DevOps has significant advantages for continuous security when best practices are followed.

    • New security tests that are necessary to test a software change are created together with the code and integrated into the trunk branch at the same time the code is. The new tests are then used to test the code after integration.
    • Security tests for each DevOps pipeline stage are automated and may be selected automatically according predefined criteria.
    • Release regression tests include security tests. At least 85 percent of the security regression tests are fully automated and the remaining are auto-assisted if portions must be performed manually.
    • Test results that indicate possible security concerns are tagged for security analysis.
    • Dynamic or interactive application security tests exercise the application for security vulnerabilities. Results of these tests are delivered to developers through tools and feedback loops native to their organization.
    • If containers are used, image repositories are scanned for images with known vulnerabilities, hash checks for image drifts and run-time checks for vulnerabilities during image deploys.
    • Attack patterns, abuse cases and tests are built for application module profiles.
    • Unit, functional and integration tests around—and especially outside—boundary conditions are run during CT. Tests include error handling, exception handling logic and negative tests.
    • Automated security attack testing to include the OWASP Top 10 in integrated into automated testing.

    Continuous Monitoring

    Continuous monitoring (CM) of security considers the dynamic nature of artifacts and infrastructure and a proliferation of objects and services to secure.

    • Metrics and thresholds are automatically gathered, calculated and made visible to anyone on the team that subscribes to them. Example security metrics include:
      • Number of security defects identified pre-production
      • Percent of code coverage from security testing
      • Number of failed builds due to security checks
      • Mean time to detection
      • Mean time to resolution
    • Vulnerability information in consolidated to provide a comprehensive view into vulnerability risks and remediation across tools, pipelines and apps—and over time.
    • Metrics and events from production security controls such as WAF, RASP, etc., are used to improve security testing.
    • Insight into security threats and events are shared and visible across DevOps teams to enable “attack-driven defense” methodologies.

    Continuous Security

    Continuous security (CS) is itself a distinct pillar with standalone best practices that cross all of the other pillars.

    • All information security platforms that are in use expose full functionality via APIs.
    • Immutable infrastructure mindsets are adopted to ensure production systems are locked down.
    • Security controls are automated so as not to impede DevOps agility.
    • Security tools are integrated into the CI/CD pipeline.
    • Source code for key intellectual property on build or test machines are only accessible by trusted users with credentials. Build and test scripts do not contain credentials to any system that has intellectual property.
    • External penetration tests (done out of band) are scheduled either periodically or on a regular cadence are used to perform deep-dive analysis.
    • Telemetry from production security controls such as WAF and RASP are delivered back to development teams to inform application updates.
    • Accurate inventory of all software packages and version information is documented via infrastructure as code. Automated detection is used to identify whether any of the packages have known CVEs associated and define specific remediation actions.

    Elastic Infrastructure

    Elastic infrastructure environments offer advantages compared to legacy or traditional static infrastructure. However, elastic infrastructures need to follow best practices for continuous security because flexible infrastructures offer a broader range of attack surfaces.

    • Configuration code includes automated checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Development tools are not installed on production.
    • Security-approved OS, software versions and frameworks are used to compose required infrastructure. Security-related controls such as ACLs and FIM are defined as a part of infrastructure where applicable.
    • A least-privilege model is enforced for processes running on shared infrastructure.
    • Smaller clusters are used to reduce complexity between teams.
    • Service provider partners security controls are validated to ensure they meet business requirements in their domains of the shared security model.
    • IaaS or PaaS service provider security controls are validated to ensure that they meet business requirements in their domains of the shared security model.

    Continuous Delivery/Deployment

    While DevOps enables new feature deliveries to users quickly, to minimize risk during deployment the following best practices are important:

    • Release-to-production decisions are determined according to predetermined metrics, which include security metrics.
    • A whitelist policy for application segmentation is enforced during deployment for each environment, especially production.
    • Continuous deployment processes trigger run-time security and compliance checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Verify development tools are not installed on production.
    • All secrets used for deployment are vaulted and retrieved programmatically during run-time or initialization of the continuous delivery process.

    In this article we detailed best practices for nine pillars of continuous security, otherwise known as DevSecOps. While is it clear that DevOps offers immense value for software deployment, the adherence to best practices is essential to reduce risk and assure security. Each organization is different and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization.

    Aggregation of end-to-end security metrics, from planning through to operations, is important but beyond the scope of this blog. End-to-end security monitoring tools, such as value stream management applied to DevSecOps and enterprise security dashboards, is a topic that we intend to cover in a subsequent blog.

    This article was co-authored by Imran Chaudhari. Imran is a principal security consultant at Trace3, where he assists clients in assessing and designing cybersecurity initiatives from a strategic, organizational, and technical perspective. His experience covers expertise in secure software development, application and cloud security, as well as identity and access management and DevSecOps assessments.

    — Marc Hornbeek

  • Security and Speed: Why DevOps and Security Need to Play Nicely

    Security and Speed: Why DevOps and Security Need to Play Nicely

    It isn’t news that DevOps and IT security teams often struggle to align their departments and maintain a coherent balance between keeping a business secure and developing new applications to maintain customer interest. While security processes are a necessity, they can be deemed by DevOps teams to be manual and cumbersome, blocking the agility that makes them so effective in bringing their solutions to market. IT teams conversely feel their counterparts are prepared to sacrifice security in the name of innovation and revenue.

    Even if both teams do respect the other’s intentions, any conflict could lead to delays in both of their processes. For example, an IT team may need to make crucial updates to the network security and warn different teams they may experience some downtime during this crucial implementation. However, DevOps have typically been given more leeway in how they operate as they are so important in today’s software-driven world, and may ask for the update to be delayed so they can complete tasks or meet deadlines, leaving the IT team waiting and losing time rescheduling their own work.

    This has, unfortunately, led to a myth that DevOps teams choose to ignore security. In reality, developers are keen to know that their apps and the environment they work in are secure—but at the same time, they don’t want security to get in the way of them quickly delivering valuable new products and software features.

    So, is there a way for DevOps teams—one of the most important resources in many modern businesses—to embrace security without impacting agility? Can the integration of DevOps and security be done in a way that alleviates tensions and promotes collaboration, while actually improving both security and agility in the process?

    Yes. The secret is automation.

    Reconciliation Through Automation

    As C-suite executives are now more likely to focus on security, due to the obvious financial and reputational consequences of a breach, DevOps teams should define how they protect and secure their multiple projects and production environments. Automating security as part of the CI/CD process allows DevOps teams to easily follow company security policies because they will be embedded into the automation pipeline.

    This process can remain running with little concern, effectively minimizing stress about security. This still automates policy changes and activities so that there is a significantly reduced chance of error. Although the automation solution remains hidden, it can still be utilized at any point to view data on the vulnerabilities, compliance requirements, security policies and network connectivity, via its continuous scanning abilities.

    Additionally, DevOps teams are already familiar with automated tools in their daily operations and communications—and they are likely to be accepting of switching to a security solution that integrates with their existing processes.

    Automation is the key to creating reliable, effective and connected “DevSecOps” teams, as it makes the secure option the easy option. It combines DevOps’ existing use of automated tools to achieve their ultimate goal of continuous, on-time and on-budget deployments with security’s focus of reducing human error and maintaining continuous visibility into potential vulnerabilities.

    Encouraging Adoption

    A guiding principle of DevOps is collaboration, which is often equated with the idea of shared responsibility. To successfully embed security into the DevOps process, security teams and developers must work together and establish shared responsibility. But how?

    Some organizations may assign a security representative in each development team. This person acts as a pivotal link between the two teams, improving communication and building a balanced process that considers everyone’s mutual interests. A continuous flow of knowledge-sharing among both teams ensures a level of maturity that allows a business to secure applications and services with an automated solution.

    Security teams can begin to define “guardrail policies” that allow development teams to deploy continuously, with the caveat of having to obey security and compliance policies. This is critical for both teams. This new way of working means developers will be able to test their security posture at every step in the CI/CD pipeline and correct things when necessary, and security teams can comprehensively ensure security and compliance throughout the development process.

    Embracing Collaboration

    Any belief that there is common discord between DevOps and IT security teams is unfounded. While it cannot be denied that both teams affect each other, this is not due to conflict—it’s due to business needs. If the two teams work together, they can both achieve their goals and be part of a secure, innovative and profitable organization. The first step is to accept collaboration is a necessity and by embracing security instead of being concerned by it, DevOps teams can stay in control of how their needs work around IT teams’ processes. Then, an automated security solution can be deployed to improve the efficiency and outcomes of both departments—and, in turn, the entire organization. It’s time for DevOps to embrace DevSecOps.

    — Reuven Harrison

  • Today: Predict 2019 Virtual Summit

    Today: Predict 2019 Virtual Summit

    Predict 2019 Virtual Summit is finally here! The summit is happening today, Tuesday, Dec. 18 at 10 a.m. Eastern. Don’t miss the opportunity to hear from Mirco Herring, Rich Mogull, John Willis, Chenxi Wang and other industry luminaries as they offer their DevOps and security predictions for 2019.

    If you have already registered, then go here to join livestream starting at 10 a.m. Can’t make the live event date? No worries! Register for the event, and we’ll send you the replay link after the event. Click here to download the program guide.

    Predict 2019 is a free virtual summit chock full of information and education for DevOps and security professionals presented in a virtual reality environment. It is a true virtual conference, replete with theaters to view the keynotes and presentations, a conference lobby to chat and socialize and a virtual trade show floor with virtual exhibitor stands equipped with video, downloads and even prizes for participation. And did I mention it’s free?

    This year’s event offers up presentations and sessions from the biggest names in DevOps and security, as well as speakers from well-known companies who’ll be sharing what they’ve gleaned from their DevOps and security initiatives.

    Here’s what the virtual format of Predict 2019 has to offer:

    • Complete control and access over every aspect of your digital experience.
    • Live and on-demand viewing from your home or office.
    • Attend and interact using the device of your choice (laptop, smartphone and tablet).
    • Digital downloads and presentations for all the sessions.

    And, perhaps most importantly, you will have unlimited playback post-event for six months! (This is for attendees who register by December 18 only!)

    Predict 2019 is here today, at a computer or mobile device near you. Visit the website for more information or to register for this daylong event. Registration—did we mention it’s free?—also includes access to the event on-demand. To register, click on the image below or this link.Predict 2019 will feature keynotes from a lineup of DevOps and Security IT executives and industry luminaries including:

    • Mirco Hering sharing his predictions for 2019—Will AIOps take over DevOps?
    • Dr. Chenxi Wang shares her predictions on future of cybersecurity in the cloud computing era.
    • Rich Mogull’s offers up DevSecOps Predictions for 2019.
    • John Willis speaks on the on Future of DevOps in 2019 and beyond.

    In addition, Predict 2019 will include a number of featured panels with topics designed to provide even greater value to attendees. Panels include:

    • Making DevOps More Ops-friendly – Charlene O’Hanlon (host), Damon Edwards, John Willis and Andi Mann
    • The Business Value of Value Stream Mapping – Jayne Groll (host), Michael Orzen and Jeff Keyes
    • Ubiquitous Open Source Makes for Security Challenges – Alan Shimel (host), Cindy Blake, Rami Sass and Baruch Sadogursky
    • Cloud Security in 2019 – Tony Bradley (host), Chris Wysopal, Sam Bisbee and Jo Peterson
    • Continuous Testing Equals Quality – Alan Shimel (host), Anand Akela and Lubos Parobek

    Register Today at https://predict2019.com/#join-us

    — saleem

  • 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

  • Revolutionize Software Delivery with DevOps and AWS

    Revolutionize Software Delivery with DevOps and AWS

    Technology is constantly evolving—every time we think we’ve got a complete hand-holding experience on some technological aspect, there emerges a better innovation.

    When the DevOps solution emerged, organizations were more than happy to incorporate its principles. But somewhere down the line, there came DevSecOps. Innovation is an upward curve that doesn’t see a decline but rather starts another journey of its own.

    And that is what most DevOps consulting service providers are striving to produce—innovation. Ever thought about getting a cloud service to operate and innovate a DevOps process? Well, that’s exactly what AWS does to innovate the DevOps process and services. Plus there’s more. That’s Innovation + Benefits!

    Benefits the Team ‘DevOps AWS’ Can Offer

    Automate – Automation is vital to the DevOps process and more so with the DevOps processes for cloud instances. It can drastically reduce developers and operators work hours dedicated to creating bug reports, generating scripts for specific functions, performing calculations and testing code. AWS helps automate DevOps approach including software testing, adding innovation, besides accuracy, consistency and repeatability. It’s human to err but it is technology that removes any scope for error.

    Scale – AWS was designed for scaling operations. AWS brings scalability to operations allowing you to do as many things as your businesses require. It facilitates easily availability of resources to fulfill the requirement at hand. The best example of this is handling traffic spikes and downtimes without the need for manual monitoring.

    Collaborate Better – Collaboration is at the very heart of the DevOps process. The unification was essential to make the development process a systematic and organized one. AWS can quickly accelerate this process and make it the way it’s intended to be. It unifies automation and enhanced operations to deliver the promises of DevOps. Gone are the days when different departments would wait on each other for communication; this paves way for improved software delivery.

    Deliver Quality with Performance – DevOps as a working principle and AWS suite of services are individual names of efficiency. So when they come together, it’s a powerful combination of quality, performance and remarkable output. Even before the output is out, developers and operators are rewarded with automated testing, continuous delivery and better infrastructure to work with. The entire process is knitted to facilitate a smooth DevOps process.

    Secure – Just as we discussed earlier, security has definitely become a part of DevOps. With AWS automation and managed cloud computing, it becomes easier to introduce updates and deploy them frequently. In turn, it makes easy to track changes in the code and ensure that security measures are enough and running correctly.

    Some DevOps-AWS combination services that enhance the DevOps process for cloud computing:

    AWS CloudFormation: DevOps-for-cloud professionals need to create and release cloud instances/services faster than general DevOps professionals. AWS CloudFormation increases the pace of creating cloud instances by creating templates of AWS resources such as EC2 instances and ECS containers to let you construct the entire setup without much manual intervention.

    AWS EC2: AWS EC2 brings security and management features to your DevOps process, making it a more the DevOps AWS duo a more desirable combination to work with. It can run containers in EC2 instances.

    AWS CloudWatch: This is an AWS monitoring tool that helps you track every AWS resource. Additionally, it enables DevOps experts to use third-party monitoring tools.

    AWS CodePipeline: This service is a popular AWS feature that eases the management of continuous integration and continuous delivery tools. It allows you to integrate tools such as CodeDeploy, GitHub and Jenkins so that you can visually control the flow of apps from scratch to the end.

    Not a service or tool but the next on the list is more like a functionality feature:

    AWS Instances
    AWS creates and adds new instances to its list. The flexibility to customize along with these instances makes it easy to use AWS DevOps together.

    Conclusion

    If DevOps is a solution, then AWS further enhances that solution to make businesses deliver their best. No wonder our world is being dictated by speed and quality!

    — Veritis

  • How to Become a DevSecOps Engineer

    How to Become a DevSecOps Engineer

    The popularity and success of DevOps means it’s now an increasingly common feature in IT job descriptions.

    One of the most important roles within DevOps, however, is the Security Engineer or DevSecOps Engineer. This deeply rewarding career requires a specific technical skill set, current knowledge of cybersecurity trends and a decent amount of experience.

    Perhaps the best thing about this role is that demand is rising. You’ll find the need for such engineers is sky-high right now and will continue to rise as cyberattacks grow in frequency and sophistication.

    What Does Being a DevSecOps Engineer Involve?

    The work of a DevSecOps Engineer is like many other IT security professional roles. Both use a variety of best practice tools and methods such as cybersecurity software, threat modelling and risk assessments to detect and analyze threats.

    However, in keeping with DevOps practices, there are some key differences when compared to a typical IT security role.

    On DevOps projects, security isn’t an afterthought but is built into the software while it is being created, by using secure coding. During development, the software is attacked to find vulnerabilities, as opposed to running scans once it has been created.

    Collaboration is a core practice of DevOps, and therefore DevSecOps roles work alongside DevOps Engineers to ensure that security vulnerabilities are assessed and fixed during development. Automation tools to detect vulnerabilities play a key role, so DevSecOps need a good understanding of such toolsets.

    Knowledge of threats is shared with the whole team, instead of keeping it within the Ops silo team. Therefore, DevSecOps Engineers require great communication skills.

    What Skills Are Required?

    DevSecOps Engineers require a broad set of skills. They need the technical skill set of an IT security professional, as well as knowledge of the DevOps approach. They’ll also need a passion for cybersecurity, with sound awareness of the latest threats and trends. These are the main skills required:

    • Knowledge of the DevOps culture and principles.
    • An understanding of programming languages such as Ruby, Perl, Java, Python and PHP.
    • Strong teamwork and communication skills.
    • Knowledge of threat modelling and risk assessment techniques.
    • Up-to-date knowledge of cybersecurity threats, current best practices and latest software.
    • An understanding of programs such as Puppet, Chef, ThreatModeler, Checkmarx, Immunio and Aqua. They may also need to know Kubernetes, Docker or AWS.

    Such skills can be acquired on the job, either in formal employment or through an internship or work placement. You can also take courses to learn DevOps principles, programming languages or automation tools. Of course, you can also teach yourself such languages and tools, as many IT engineers tend to do.

    What About Experience and Qualifications?

    Many DevSecOps Engineers have experience in a non-DevOps IT security role. If you have no experience as an IT security professional, it is recommended you start there first before getting into DevSecOps.

    Starting a career in IT security generally requires a degree in computer science, cybersecurity, math, engineering or science. It is then recommended you gain experience on an internship or graduate placement. You can also enter the field without a degree by gaining practical industry standard certification, such as that offered by Microsoft, CompTIA, Cisco or Certified Ethical Hacker (CEH).

    Making the move into DevOps requires IT security experience, and you’ll need to gain knowledge of the languages and automation software commonly used on DevOps projects. It is also advised that you gain accredited DevOps qualifications from the DevOps Institute, specifically the DevOps Foundation and DevSecOps Engineering (DSOE) qualifications. These will equip you with a solid understanding of DevOps principles and DevSecOps methods.

    Summary

    You might think DevOps or DevSecOps are just trendy words for developers, operations and security teams who work closely together. But this is wrong. There is so much more to DevOps than that. Ask Netflix, Amazon or Sony—all hugely successful companies that use DevOps culture to get things done.

    DevSecOps is a crucial part of DevOps, especially given the current cyberattack climate. As the need for such individuals grows, so will the job openings. If you have security experience and want to boost your career or are thinking about which degree and career path to take, keep DevSecOps in mind.

    — Stephanie Rowe

  • DevOps Chat: DevSecOps with Signal Sciences’ James Wickett

    DevOps Chat: DevSecOps with Signal Sciences’ James Wickett

    James Wickett is the man to go to for DevSecOps. The founder of the Rugged DevOps movement, which has merged into the DevSecOps group, James is one of the most knowledgeable people on the subject of DevSecOps.

    In this DevOps Chat, James shares his views on what’s on the horizon for DevSecOps and the most important things we can do to make our teams more secure. Have a listen as James gives us his take.

    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. I’m really happy to be joined on this DevOps chat by one of my friends from the Austin boys, James Wickett. James, welcome.

    James Wickett: Hey, thanks Alan. Really glad to be here.

    Shimel: It’s my pleasure to have you here. So for those of you who may not be familiar with James, you know, James is really one of the lynchpins in the, for my money, the best DevOps community in the world and it’s the folks over in Austin with Ernest Mueller and James and Karthik and Boyd and just a whole bunch of great people coming out of Austin. But when James isn’t busy building the best DevOps community around, he also works at Signal Sciences and of course James was also kind of the founder, prime mover behind Rugged DevOps and now DevSecOps, as well as with Shannon and those folks. So, I hope I didn’t make you blush, but –

    Wickett: That’s all right. We loved having you come down to Austin and we’re pretty proud of the – you know, it feels like the InfoTech community here in Austin is really close knit and there’s a real family dynamic to it, to a certain sense, the good kind of family. I know that can be different for different folks, but you know, it’s very nice that we’ve been able to do that for so many years and we’re excited for bringing DevOps days Austin, continuing to come back year after year, and your partnership with that has always been great, Alan, so we –

    Shimel: Yeah, no, it’s my pleasure. I don’t say it lightly, especially this past year and a half, two years, I have probably been to more DevOps days and DevOps events around the world, not just here in the US. And Austin’s a special, special place for it. James, as we were talking off camera a little bit, you know, over here at devopsy.kinsta.cloud and the rest of the media op sites, we’re doing an event called Predict 2019 and it’s a virtual conference. It’s more than just kind of like a video like this where it’s actually a virtual conference where the sponsors have booths and there’s a whole session auditorium and everything, but the idea behind it is really to put on our crystal ball hats and take a look at, hey, what does the near term future look like? You know, if we’ve been in tech long enough, we know better than to make a long-term future guess.

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

    Shimel: Right? Who knows? But, near term we’ll try. So, I wanted to spend a couple minutes with you and talk about what do you see 2019, the next 12 to 18 months. What’s factored in on the DevSecOps scene, on the DevOps scene, on AI Ops, on you know, just what we live in day to day, James?

    Wickett: Yeah, yeah, that’s right. Yeah. Well, that’s a good question because when you think about DevSecOps and where it is today, I think, I always hope that we’re further along than we are, and the data still shows that like we have some ways to go. There is a SANS survey on secure DevOps and kind of the joining of just security and DevOps and where it is in the current state of the world and Signal Sciences, along with several other sponsors, are happy to kind of be a part of that survey and that research, but one of the things that is pretty astounding out of that whole piece is that 95 percent of securities responsibilities or 95 percent of security people reported that their main kind of thing they were doing was supporting legacy applications.

    So, and it’s real telling that we see this – we’re seeing really in security and DevOps kind of the same problem we had with Dev and Ops, you know, ten years ago, right, this whole throw it over the wool mentality, you know, different groups value different things. Developers valued feature speed and deployment ability, I guess. Operations valued stability, reliability, things like that, and they always felt like they were at odds. Well, security comes in as sort of this third wheel here and what does that do to the mix?

    And I always – I’m really happy like to be spending time with some of our customers at some events and I get to hear stories of people doing things that are radically different than securities done over the last decade, but to say that that’s not – to say that that’s ubiquitous would be false. Like that is just not where we’re at right now and I think it goes back to that quote, right, and I think this helps us with this 12 to 18 month prediction piece. Like the future is here, it’s just not widely distributed. Right?

    So, I can see what leading high performing companies are doing and I can just say, next 12 to 18 months is like more people doing some of that stuff, and I’m excited about that.

    Shimel: I agree with you. You know, James, this is something that I, you know, I’ve always kind of felt is that, you know, we certainly suffer from shiny trinket syndrome and we always want to know what the next great thing is or what’s the next big thing. But what we often forget about is the whole world isn’t a green field. It would be so great if we only had green fields and new apps to work on.

    Wickett: That’s right.

    Shimel: But we live in a world of legacy apps, right? We’re going – no one’s throwing out their mainframes. No one’s going to just throw away all of these applications that have been built. Excuse me.

    Wickett: Yeah, we live in the brown field, Alan.

    Shimel: Right, we live in a very, very brown field and so to me, should we be focusing near term at modernization, right, and how are we – because at the same time we have these legacy apps, James, we have such new infrastructure possibilities with, you know, so how do you containerize and Cubernettisize and make servo lists, all of this brown field application and at the same time, I really think that’s an opportunity for security.

    Wickett: That’s right, yeah.

    Shimel: To come in and let’s do it right. Right?

    Wickett: Right.

    Shimel: Let’s fix something that really wasn’t set up right the first time.

    Wickett: Well, and the inverse or the – there’s another layer to that problem is that we’re seeing people in the security space that are almost cutting edge for like what we would call like DevSecOps and people that are doing great, but they’re all coming from like large enterprises, which is a really weird thing because innovation from the DevOps space came from like small, medium sized companies that were able to be nimble and be fast, but when you’re at a certain size, you don’t have security talent on hand. You don’t have anybody on staff and you’re also – you have a different set of concerns. Right? Your concerns are staying in business for the next several quarters.

    Shimel: Right, keeping the lights on.

    Wickett: Right, when we’re seeing people like Shannon Lietz over at Intuit or we’re seeing Topo over at Capital One, right, or Chitra Elango over at Fannie Mae, right, we’re seeing these stories and the way that people are piecing together pipelines and they’re tying all these security things into these DevOps movements. They’re all coming from big companies and I don’t think there’s – I think there’s definitely a connection there. We’re going to see some of that security wisdom and kind of learning of how to do DevSecOps come from the other end of the spectrum, which I think is a really cool thing.

    If you’d have asked me three years ago, I would not have predicted that at all.

    Shimel: No. So I’m going to tell you, along those same lines, James, to me, this may wind up being the hidden gem or the hidden legacy of DevOps. When I first launched devopsy.kinsta.cloud and you were around, you remember, you know, besides everyone yelling about making a commercial, there was this huge argument raging between people about startup DevOps versus enterprise DevOps, you know, could enterprises do DevOps, was it a unicorn thing? And you know, some of the – I always felt that the right answer was, there’s only one DevOps. Right? There’s not a startup DevOps and an enterprise DevOps.

    But, different organizations have different things. I think what we’ve seen over the course of evolution is that yes, DevOps really kind of took hold in the small midsized businesses out of necessity, but enterprises shaped and molded it and made it work at these large enterprises, and in doing so, created opportunity for the security folks, the QA folks. Right? All of these other silos, right, that maybe you didn’t have in a small company, right, because everyone wears like seven hats.

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

    Shimel: Right? But, at the enterprise level, it’s giving it a chance to flourish and to – it’s like a giant petri dish, right, and so it’s great and it’s giving security people a chance to get in here. So –

    Wickett: Well, and you look at, you know, you have a vision of like, hey, let’s put this for, this is not just for startups and west coast companies. This is something that can hit across – and I love that. I love going to middle of America, DevOps Days events like the Kansas City one was quite _____.

    Shimel: Kansas City was pretty cool, yeah. Right.

    Wickett: And I liked it because it’s people at larger companies wrestling with these problems, trying to make this happen and I’ve been lucky enough over the last several years of my career to do a lot of green field type stuff, but that’s not the yeoman’s work. The real tough work that we’ve got to do is DevOps transformations in these large enterprises. And you and Jean Kim through the DevOps Enterprise Summit we see stories of these types of transformations happening and seeing security being brought into that. I mean, it’s just–it’s really pretty cool.

    Shimel: Absolutely. So, now not to prod you along here, James, but –

    Wickett: Yeah, prod me. Prod away.

    Shimel: I see it, so we’ve had a chance to build a little bit of a foundation. Right? We see these things happening at the enterprise level. Kansas City, Chicago’s another great example. Big companies, right, talking about their DevOps and their DevSecOps. How do we build on this momentum, James? What shape does that take? As security people, what do we need to do to move that needle?

    Wickett: Yeah, that’s a good question. Let me – can I take two answer on that and –

    Shimel: Sure, take three if you want.

    Wickett: Sure, all right, good. Well, I think there’s – let’s start with the first answer. I think we’re still developing a mental model or some sort of platform of like how the delivery pipelines work. I mean, of course you can go to any number of talks, you can see how our people have assembled them, the tooling that they’ve put in place, but security has a lot of success whenever they can look across the – whatever the software delivery value chain and say, “All right, how are we delivering the software and where is our build system or our development process and then how do we deploy and deliver all the way to the customer?” And look across the broadly and find discreet tools that they can add in those places, and not just tools for like software, but like practices or ways to transform. Take the ISC squared, CISSP manual and rip out a good – a lot of the waterfall bits, but figure out like were does this change, like in the modern world? And I think that’s – I’d say that’s like the first approach that I would like to say.

    I think philosophically, I would – I’ll kind of answer you with a situation that I was posed with recently. A friend of mine, he works at a large enterprise company. They are not cloud, just now thinking, “Hey, maybe we should do this cloud thing.” And which I – some people that are listening to this are like, “What?” But that’s just the way it is. People are –

    They have so much investment in the data center that like now it’s like they finally kind of said, “All right, we have some new stuff that we’re building. We think the cloud is where we should do it and we’re hearing these things like Cubernettis and servals and containers and whatever.” Right? “So we’re trying to figure out what direction we take with all this.”

    So now some of these companies, legacy type companies, are putting resources towards it. Well, this guy is a security guy and he had them kind of come in and say, “You’re going to DevOps the thing and DevOps is going to be the way.” Right? Not really – this is a company where maybe they’re not even really sure what DevOps really means. Right? Which is okay. They’ve heard it. They’ve got some of the vision and they’re interested.

    He’s very concerned. He says, “James, what do I do about this? I know you like the DevOps and stuff like that, but you know, what do I do from a security perspective.” I give him an answer. I didn’t feel great about it. I gave him a, you know, I don’t know, find ways to inject stuff, I don’t know. I went home, thought about it, woke up the next morning and I was like, “I got to call him back.”

    So I gave him a call and I was like, “Hey, the real answer to your question is never say no ever again. Never say no ever again. Security has lived the world of no for so long and you have to throw that away. Like your new answer has to be yes, you can have yes with qualifiers, yes with whatever, but you’ve got to find ways, creative ways to say yes and kind of the cloak and dagger, blame it on compliance, slowing down things for whatever, you can’t do any of that stuff anymore and you’ve just got to throw out all the security gets to be a blocker.”

    And I said, “Because every organization that I see high performing, what we would now call like DevSecOps teams, but security and DevOps working together, they sort of rip tear up the security playbook and they say, if you are a blocker, everyone in the organization is going to route around you. But if you play ball, like you get to be a part of the solution. And security has to find a way to add value inside of that.”

    And so, and I said, “Every single one, you talk to any person who’s undergone the transformation and working in any of these companies to Hulu to Netflix to Inuit or whatever, you know, or all the ones that we see at DevOps Enterprise Summit, they’re always finding ways to say yes and be part of the solution and not to see themselves as a blocker. So I think that’s a fundamental like philosophical shift that security has to undergo.

    Shimel: Absolutely, and you know, just to turn it around on you a little bit, I’m going to be the Jewish guy spreading the good news too, right, the gospel. We started off this conversation early on and you said, “Well, we still have so much more to do and I wish we would be further along.”

    Wickett: Yeah.

    Shimel: You’re right, but someone much smarter than me once told me, James, change, especially in technology, is 99 percent of the time evolutionary, not revolutionary.

    Wickett: That’s right.

    Shimel: But, when we look back over a period of time, we’re often astonished what that evolution – how that evolutionary change adds up. So the fact, that little piece that you espouse right there about not saying no anymore, and yes, we can and you know, whether you qualify it, caveat it whatever, but yes, we can.

    Wickett: Yeah.

    Shimel: It’s so powerful. It really is. It’s so powerful. Look, I spent 2001, I’ve spent 18, 19 years hearing now from people, and – or being part of the no too, to be in all honesty.

    Wickett: Right, yeah. I mean, that’s –

    Shimel: You don’t want to wind up in jail, do you?

    Wickett: I got my ISC squared books up there. They look at me with an evil eye.

    Shimel: Yeah, so you know, it’s refreshing. It’s like liberating to take that attitude. How do we spread this gospel though? What more – what better way can we do it? I know you’re involved in DevSecOps.org and DevSecOps Days and I’m obviously too and at RSA this year, we’ll be doing our thing again. But what more could we do in 2019, James?

    Wickett: Oh man, that, I don’t know the answer. I don’t know the answer to that question yet. I mean, I think there’s some pragmatic things. I think we continue to say the story side. I relate to what’s going on with security right now to what happened with DevOps in the beginning and if you rewind to like 2009, 2010, or like let’s say the first three years, right, DevOps equaled chef or puppet, like straight up, like that’s what it was. And so what was that? That was operations was finally able to be developers, to act like developers, to shift left. Right?

    They participated in agile type practices with infrastructure, revolutionary, really cool, really great. But then there was also another movement that happened at the same time and that was the idea that like we needed the instrument a lot better. We need to do monitoring. Now, people talk about observability. There is a big push of understanding like what your systems are actually doing. So, and that was, then there’s kind of the whole like monitoring conference, there’s monitorama, there’s monitor movement and the monitorama in response to it.

    There’s some great products have come out of that space. We see things like Data Dog and before them Cloud Kick and other folks. Well, I relate all that to security because if you look in the first several years of this security and DevOps kind of joining forces, I know people have been talking about it for many years, but over the last couple years, what are the things that everybody has kind of gone around? It’s the whole idea of shift left. So you see great companies, _____ types, Nick, other folks like that, that are focusing on, you know, putting all of your development testing, you know, figuring out what binaries, talking about software supply chain, bill of materials, all that sort of stuff. We’re still missing the push right.

    Now, I mean, I work at a – or a shift right type thing and so like, Signal Sciences, we sit at that end of the spectrum, so this is a bit of a self-serving type statement, but I mean, you need to have sort of insight into sort of what your application is doing and when we started the company, we were singularly focused on one question and that question is, do you know right now if you’re under an attack with any degree of certainty, we’ll say. You don’t have to know 100 percent, but with any degree.

    I ask people that question like in conferences and whatever and almost zero, like I’d say just one or two people per, y, every six months or whatever, says yeah, they know. Most people have no idea, like what’s actually going on in their site. And we see this like when was the last time you read the headline that said, like, you know, we lost a million account credentials, but we stopped them. We’ve been following them through our system, we saw that they were starting to leak data and so we turned it off, but we didn’t get it off soon enough, but they didn’t get 100 million, but they got a million. Right? You never see that news story. Right? You see the news story of like _____ we lost it all and we lost it all three months ago. We had no idea until it started being traded on the market. Right?

    So, like we lack a critical insight and you know, operations had the same problem, right, didn’t understand what was going on with the systems, performance-wise, everything. Security is quite similar to that. So, being able to instrument and see and do monitoring and have that sort of security observability is like an important aspect to where I think we need to go. So, we’ve done a lot of the shifting left similar to ops in the early days, and I think we’re going to see some more movement on the shift right part.

    Shimel: It also sounds though like opportunity there for some better tooling.

    Wickett: Yeah.

    Shimel: Right? I mean, a lot of our security tools, you know, from vendors really aren’t made for that, right? I mean, you know, we have so much – so you know, the fighting point in the security vendor space is, should we put more focus on security response versus prevention? Right? Threat intelligence, all of these things, and you’re right. We don’t have that analog of a Data Dog, a Signal FX or that, for the most part, in securities.

    Wickett: Yeah, ’cause like I see that across like – so for Signal Sciences, like we provide that for web applications, but that’s also stretching across other boundaries that you need to look at, and a more fuller picture, and I remember whenever we were launching – when Ernest and I were doing cloud stuff at our first just kind of thing over at National Instruments, we were trying to find vendors and just straight up like operational monitoring vendors and I talked to like – that was my job. That was one of my first parts of the things.

    It’s like, okay we built the thing that – we have this whole thing we called Pie that spun up our system, much like Chef and Puppet, but then we said, all right, what are we going to monitor this stuff with? And I started calling and monitoring vendors and getting demos and stuff and it’s like, at the end of it, I was like, I just need one that has an API. Like just a good working API that can like admit _____  _____ and connect, you know, ’cause this is early days. Right? And we ended up finding a Cloud Kick and they ended up getting bought and sold and we moved later on to Data Dog, but it was so hard at the time to find that. And I feel like security vendors are similar in that space, that they struggle from where like when – and we’re not alone in this. There’s other people in our space that are doing thing that are helpful for people, but emitting data back to all the systems that you work with, like the Slack and JIRA and whatever, but also just being part of like the whole tool chain approach. And I think that’s a story we’re going to see continue to be developed and companies that are adopting that and embracing the idea that they’re a piece in the overall tool chain, like I think those companies are going to continue to do well.

    Shimel: I know that you can have like just standalone security monitoring and so I think security monitoring has to be part of your larger monitoring.

    Wickett: That’s right.

    Shimel: Two or three other points I wanted to hit on, get your opinion on. So, just like DevOps, same analogy, tools are important. Culture trumps tools in a lot of places and we can have the best tools in the world, but until the security people’s mindset is changed and we’ve touched on it in this talk, you know, not saying no anymore and all of that, so how do we go about changing that mindset? Well, one piece of it, James, is at the organizational level, right, we embrace security.

    We make them part of the team. Another part of it though is at the community and industry level and we mentioned it now a few times and a lot of my friends mention it, and this is the whole what are security people taught. And I’m not knocking ISC Squared or SANS or any – we’ve got some –

    Wickett: Let’s knock them. No, yeah.

    Shimel: I’ve got friends on the board there. You know, I got to be careful. But, I mean in all honesty, and again, I’m not singling any one of them out, but when security people are being taught to say no, it’s very hard for us to come in and say, “Don’t say no.”

    Wickett: Yeah.

    Shimel: Right? So, do we, you know, you know I’m part – I’m one of the cofounders of DevOps Institute and we have a DevSecOps class there that you know, some of my more enlightened friends have helped us with. You and Ernest have done the DevSecOps thing. You guys do _____ and stuff like that. But those messages, I don’t know if they’re finding their way into, let’s call is mainstream security training, ISC Squared, CISSB exam, the SANS certifications and not just those two. There’s a half a dozen other very well-known ones. How do we, you know, is 2019 the year we make a beachhead there?

    Wickett: I don’t know. I don’t know. I’m an optimist, Alan, so I would love to say yes to that question. I would love to say yes, but when you think about it, like it’s – security has a very tough job. They’ve worked themselves into a scenario that they’re beholden to compliance and standards and outside bodies of influence and then they also are inside of an organization trying to affect change, but they find themselves at a very like inequitable distribution of labor. So like you have a hundred developers. You have ten operations folks. You may have one security person. Right? That’s a recipe for a problem. They’re all going to have different values.

    So, I don’t know if we’re just going to automatically fix the culture in 2019. I will say tools influence – tools have an influence on culture and that you know, in the CANS model or CLAIMS model for DevOps—or CALMS, I guess people like to call it as well, but for the M, for measurement and sharing, I think those are the two pieces that can really help influence the culture in a more positive light.

    And so, you know, security has, you know, we have stocks and we have like we – we remit all the data and have people taking concern of this, but we’re not – if you’re not creating – this is something else that I try to influence among my security friends. It’s like, if you have any tooling that you’re buying and implementing whatever, but it’s not creating a feedback loop to developers, then it’s like worthless. You should _____. Right? If it’s just going to a sock and someone’s doing it like, that’s not good. Right? There’s no DevOp telemetry out of what’s actually happening.

    And so I think finding products that can help or whether it’s like open source testing tools or you know, instrumentation on the right or detection on the left or whatever, but like creating those like, I don’t know, able – we’re able to have a sort of virtuous cycle of feedback loops to development. I think that’s going to be key. But yeah, I’m going to say like no, 2019 is not going to be the year just because of – just because of the way humans are. I would like – but I think that it’s going to get better.

    Shimel: I think it will get better. Here’s what I think we need to do, James, and you have got to do in this.

    Wickett: All right.

    Shimel: You and I are both wired into this community. We know people on the ISC Squared board. We know SANS instructors. We know the folks at SANS. We know all of these places. If one of the missions of the DevSecOps.org group, team, community, DevSecOps Days, what I do with my stuff, is to make sure we reach those people and say, “Hey, we represent a very large piece of this community and you’ve got to listen to us. It’s like a voter registration drive then. And – but you’ve got to lead it, right? And so, I’m going to put the onus back on you, James, and say you can make this a reality. You –

    Wickett: All right. Well, Alan, let me tell you how I am working on that. So I do have somewhat of a plan here or an idea here. So, I’m working with several others, Shannon Lietz, Ernest Mueller, John Willis and we’re working on the DevSecOps handbook, which is going with IT Revolution, and we’re trying to tell those stories of like how DevSecOps is transforming at large companies, small companies, helping people see the new path forward. So hopefully yeah, that’s –

    Shimel: In 2019?

    Wickett: That’s – the – what is it called, the like the draft galley copy, like we’re hoping to have some of those available in 2019 at the DevOps Enterprise Summit _____ either in London or in Vegas, so yeah, it depends on – you know, it’s a – they run a real great shop over there, so it depends on the schedule for editing and all that stuff.

    Shimel: Well, that’s a revelation. Good stuff, man.

    Wickett: So hopefully 2020, 2021, like we’ll start to see the industry really shift. You know, I do hope that – I always hope that things happen sooner than they do, but –

    Shimel: It _____ before it’s time either, my friend, right?

    Wickett: That’s true.

    Shimel: So James, I told you this was only going to be 15 or 20 minutes. I’ve got a feeling we’re at like twice that already.

    Wickett: Yeah.

    Shimel: But, it’s okay. I think it was a great conversation. People will enjoy it. Predict 2019 folks, you can go to predict2019.com. James is, of course, with Signal Sciences and you should definitely check out their site and what they’ve got going on. And also just a quick reminder, RSA conference is here March 4 this year. And we are doing our DevOps Connect DevSecOps Days at RSA Monday March 4, so if you’re going to RSA, come a day early, come in at the Moscone Center, Shannon the whole crew _____.

    Wickett: Yeah, if people are listening to this and they haven’t been to that, like, you’ve got to go. Like, I think that’s a very valuable single day track that’s really helpful. And also, some of the sponsors and vendors back there, like some of the really forward-thinking folks, I mean, it’s the – it’s really like the part of RSA that I feel like has really kind of anchored that for me in my experience at RSA. It’s like “Oh, okay. Here’s the crew. Here’s what we’re trying to do.” I can see the message going out, and I love the fact that kind of the vision, did you decide to start that or is that –

    Shimel: That was me.

    Wickett: That’s – I think that was good because –

    Shimel: DevSecOps Days, I just – you know, I – so I have a relationship with RSA for 15, 20 years and I originally went to them with it. This is the fifth year we’re doing it. I’m really pumped. I mean –

    Wickett: Yeah, well, and thank you for that because basically like we – I’d say one of the ways we make the transition is by going to security events and kind of helping make this happen.

    Shimel: Yeah, raising the flag.

    Wickett: Yeah, and you – that is an outpost for DevOps over at RSA, RSA of all conferences. So –

    Shimel: Yeah, if we can do it there, we can do it anywhere.

    Wickett: I agree. I agree.

    Shimel: All right. Hey, James Wickett, Signal Sciences, thanks for being our guest on this DevOps Chat. James, thanks for all you do too for the community and everything else. Keep up the great work and we’ll speak to you soon.

    Wickett: All right, thanks Alan.

    Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud Security Boulevard. You’ve just listened to another chat. Have a great day everyone.

    — Alan Shimel

  • The State of Web and Mobile DevSecOps

    The State of Web and Mobile DevSecOps

    As the leaders in coverage of the DevOps world, the reporters here at devopsy.kinsta.cloud are constantly pressed upon to convey the true state of DevSecOps at any given moment in time. We try to dig up the state of the union by asking important questions of IT executives, DevOps champions, security leaders and other pundits. The answers we get offer illuminating narratives of the DevSecOps journeys in global organizations across a wide range of maturity levels. But, at the end of the day, these are anecdotal at best.

    We know that nothing beats hard data, which is why we’re partnering with NowSecure to field a new survey that we hope will offer solid numbers around secure DevOps maturity and adoption practices.

    With this survey, we hope to do a couple of things: First, we obviously want to provide insight into how well organizations are automating their software delivery and application security (appsec) testing practices across their entire software portfolio. We’d like to understand the perceived benefits organizations have for folding security into DevOps and the inhibitors.

    Second, though, we want to take a deeper dive into where DevSecOps is specifically when it comes to delivering mobile applications. There’s not a lot of visibility into whether there’s a different set of standards, practices or benchmarks for mobile software, but we have a hunch there might well be a gap. We can’t be sure until we’ve got some data to show where the industry stands when it comes to mobile DevSecOps.

    Which is where our esteemed readers come into the picture.

    We’re asking executives, managers and practitioners to take our new survey and let us know how things stand in their organizations. We’re looking for respondents from a range of backgrounds—be they DevOps engineers, developers, architects, security pros, operations gurus or QA professionals. Help us out so we can provide important data back to the industry.

    — Ericka Chickowski

  • 5 Questions to Ask When Choosing a Cloud-Native Security Platform for DevOps

    5 Questions to Ask When Choosing a Cloud-Native Security Platform for DevOps

    If you work in DevOps, you’ve likely heard the mantra that DevOps success is all about the right people, tools and processes.
    Below, we take a look at how you can address the “tools” part of that equation when it comes to security. Specifically, we’ll discuss which questions to ask and what features DevOps teams should look for when choosing a security tool for today’s cloud-native infrastructures.

    What is Cloud-Native, and What Does It Mean for DevOps?

    Our discussion is informed by two main considerations. First, we’re going to focus on the security challenges that arise in cloud-native environments—which means those built with technologies that include, but are not limited to, containers, serverless functions and (of course) virtual servers.

    Second, we’ll focus on the security needs of DevOps teams. Although DevOps positions may not explicitly involve security, we now live in the age of DevSecOps, and everyone on the DevOps team has a role to play in keeping infrastructure and applications secure. In this article, we’ll consider which types of tools are best-suited to help DevOps teams do that, while also promoting the visibility and collaboration that are essential parts of a healthy DevOps strategy.

    So, those are our goals. Now, let’s look at the questions you should ask as you evaluate cloud-native security platforms for a DevOps organization.

    What Are You Actually Securing?

    This question may seem obvious—so obvious that you may not give it much real thought. But because today’s infrastructures and environments vary so widely, it’s important to step back and figure out what, exactly, you need to secure.

    Are your workloads running in containers? Are you also using serverless functions, or do you plan to add them? How are you orchestrating your workloads? (With the native orchestrator provided by your cloud vendor, Kubernetes running as a service, your own Kubernetes build or something else?) Which new cloud-native technologies do you expect to adopt in the future?

    Answering questions such as these is important to ensure you choose a security platform that can support all of your current and future cloud-native environments. In most cases, you’ll find that security platforms that are purpose-built to secure a range of environments (not just containerized ones, which are usually the focus of most self-proclaimed “modern” security platforms) are the best and safest fit for your needs.

    What Are Your Security Threats (and How Can You Stop Them)?

    This is another question that might seem overly obvious. But here again, the fast-changing nature of threats means that it’s worthwhile to take some time to assess what your threats actually are.

    Keep in mind, too, that the threats faced by your particular team, or the app you deliver, may be different from those that threaten other teams. This is one place where the DevOps principle of cross-organization communication is crucial for effective security management.

    Which Layers Does the Security Platform Secure?

    Scanning container images for known vulnerabilities is good. On its own, however, it hardly amounts to a complete container strategy. The same could be said for setting up a firewall or locking down access control.

    To achieve true security, you need to secure all layers of your infrastructure (including those managed by other teams) against all vectors of attack. For that reason, you want a cloud-native security platform that is designed for holistic security, not a tool that only secures one or two layers.

    Where Does the Security Platform Get Its Vulnerability Information?

    When it comes to identifying vulnerabilities, security platforms can get their information from lots of sources. They could look at a public CVE database or at a list supplied by the tool’s vendor.

    The best security platforms, however, will pull vulnerability data from multiple sources. After all, if you’re only relying on one data source to figure out where the threats are, you are unlikely to catch them all—and just like in the world of Pokémon, catching them all is one of your main priorities for DevOps security.

    How Automated is the Platform?

    Automation is the mother of DevOps (or something like that).

    What I mean is that without automation, you can’t do DevOps very effectively.

    You also, incidentally, can’t do cloud-native security unless you rely heavily on automation. That’s because the highly dynamic nature of containerized, serverless and other cloud-native environments means that trying to interpret all of the data they generate, identify vulnerabilities and react to them manually just doesn’t work. That’s why you want a cloud-native security platform that automates wherever and whenever possible.

    You should still expect to have to perform some tasks manually, of course (which is actually a good thing—if we could automate everything, DevOps engineers wouldn’t need to exist anymore). But to the extent possible, your security platform should automate your security-related workflows.

    — Sonya Koptyev