devopsy.kinsta.cloud

Category: DevSecOps

  • 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

  • Best of 2018: 5 Open Source SIEM Tools Worth Checking Out

    Best of 2018: 5 Open Source SIEM Tools Worth Checking Out

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

     

    Security information and event management (SIEM) is the cornerstone of IT security. All other network solutions are merely data flows that feed into an organization’s SIEM. Not all SIEMs are created equal, and their capabilities can vary wildly. Choosing the right one for your needs can mean the difference between detecting a security weakness and becoming just another statistic.

    A SIEM solution is a combination of a security event management (SEM) system and a security information management (SIM) system. SEMs monitor servers and networks in real time, while SIMs store the data.

    Both SEMs and SIMs provide analysis. SEMs focus on real-time event correlation, alerting and those fancy network operations center (NOC) “something has gone wrong” dashboards that one may come across in the movies. SIMs focus on bulk data computational analysis (BDCA) of large quantities of logs.

    In other words, a SEM is designed to tell you when something is going down as it happens, and SIMs are designed to spot the subtle attacks that SEMs don’t catch. Merging the two into a SIEM solution seems like a natural fit.

    Related Content:

    The Value of Commercial Open Source

    How Developers Can Take a More Proactive Approach to Security

    SIEM stacks usually consist of at least three components for data collection, data storage and data analysis. The data in question is frequently log files, but can also be netflow traffic or other real-time data feeds.

    There are a number of SIEM tools on the market, both open source and commercial. With the rise of DevOps, containers and other modern application development methods, the open source solutions are seeing a resurgence of interest. Let’s take a look at some of the top open source SIEM tools out there.

    OSSEC

    OSSEC is a popular host-based intrusion detection system (IDS) that works with Linux, Windows, MacOS and Solaris, as well as OpenBSD and FreeBSD. OSSEC is composed of two components: the host agent (responsible for collecting the logs) and the main OSSEC application (responsible for processing the logs.)

    There is also a now-deprecated GUI, but since other open source solutions do a better job of data visualization, the OSSEC project recommends using those solutions instead. Popular open-source data visualization tools include Kibana and Grafana.

    OSSEC directly monitors a number of parameters on a host. This includes log files, file integrity, rootkit detection and Windows registry monitoring. OSSEC also can perform log analysis from other network services, including most of the popular open source FTP, mail, DNS, database, web, firewall and network-based IDS solutions. OSSEC can also analyze logs from a number of commercial network services and security solutions.

    OSSEC has a number of alerting options and can be used as part of automated intrusion detection or active response solutions. OSSEC has a primitive log storage engine. By default, log messages from host agents are not retained. Once analyzed, OSSEC deletes these logs unless the <logall> option is included in the OSSEC manager’s ossec.conf file. If this option is enabled, OSSEC stores the incoming logs from agents in a text file that is rotated daily.

    Whether OSSEC counts as a “full” or “proper” SIEM is the source of numerous internet debates. OSSEC does the hard work of a SIEM: It collects data and analyzes it. OSSEC is at the core of a number of other SIEM solutions, and part of any number of application stacks that pair OSSEC with a more advanced long-term log retention system and advanced visualization capabilities.

    Snort

    Snort is a popular network-based IDS. Network-based IDS systems differ from host-based IDS systems in exactly the way one might expect—while a host-based IDS lives on an individual server or endpoint, network-based IDS systems live further out on the network, and scan all traffic that they can see.

    Snort’s purpose is to sniff, log and perform real-time analysis on network flows. It can display a real-time stream of packets to a console, dump packets to a log file or perform analysis.

    Snort relies on output plugins to determine how and where it will store the information it generates. Snort can store this information in a flat text file, output to a database, a Unix Socket, a pager or cell phone and any number of other destinations.

    Snort has a number of filtering and pattern matching options. This means that snort doesn’t have to display, log or analyze all packets traversing a network link. It can restrict itself to information pertaining to a specific host or matching specific patterns—something that is of increasing utility as network throughput of 100Gbps on individual network links becomes more common.

    Configuring Snort requires careful planning. Dumping 100Gbps worth of packets to a flat text file isn’t the best plan, and most organizations aren’t exactly going to be able to afford to ship that kind of data off to a public cloud-based log repository, either. Judicious use of Snort’s filtering and analysis capabilities combined with output plugins are required to make Snort practicably useful.

    With a narrowly configured set of alerts, Snort’s ability to send alerts directly to a cell phone becomes meaningful. A broader set of filters could be used to pass data to a long-term storage repository for more in depth analysis by another tool.

    Like OSSEC, Snort relies on third-party solutions in order to perform visualizations. As one of the earliest network-based intrusion detection solutions available, there are a number of solutions (both open source and commercial) that exist only to visualize Snort data, making the lack of a built-in visualization system somewhat irrelevant.

    Like OSSEC, Snort’s qualification as a SIEM solution is somewhat debatable. Snort collects data and analyses it, and is a core component to more complete SIEM solutions. Snort is also part of any number of application stacks which add log retention and advanced visualization capabilities.

    It is not unusual to see Snort and OSSEC working together to each fill different niches in the grand scheme of data center SIEM needs. It is also perfectly normal to see them deployed independently, especially as part of cloud-native applications, where monitoring needs can be narrower.

    Suricata is a competing open source network-based IDS that is frequently used in place of Snort.

    ELK

    The ELK stack is arguably the most popular open source SIEM tool available, though, like OSSEC and Snort, there is room for debate about whether the ELK stack even qualifies as a SIEM on its own.

    The ELK stack consists of the open source products Elasticsearch, Logstash and Kibana. Logstash is a receiver for log data from virtually any source. It can filter, process, correlate and generally enhance any log data that it encounters.

    Elasticsearch is the storage engine, and is one of the best solutions in its field currently available. Kibana is the visualization portion of the equation, and it is hands down one of the best visualization system the open source community has yet produced.

    Logstash, a part of the ELK stack, uses input plugins to collect logs; however, it also can accept input from more purpose-built solutions such as OSSEC or Snort. Combined, the ELK Stack’s log processing, storage and visualization capabilities are functionally unmatched. The solution is powerful, but that power comes at the price of complexity and a high TCO. Cloud offerings such such as Logz.io offer a hosted ELK alternative.

    The ELK stack forms the core of a growing number of commercial SIEM offerings. These solutions bring expertise in standing up, configuring and managing the applications in the stack. They also may offer canned or easier-to-design filters for Logstash than are available in the native open source solution. Both approaches offer significant added value.

    Prelude

    Prelude is a SIEM framework that unifies various other open source tools. It is the open source version of the commercial tool by the same name. Prelude aims to fill the roles that tools such as OSSEC and Snort leave out.

    Prelude accepts logs and events from multiple sources and stores them all in a single location using the Intrusion Detection Message Exchange Format (IDMEF). It provides filtering, correlation, alerting, analysis and visualization capabilities. The open source version of Prelude is significantly limited when compared to the commercial offering in all of these capabilities.

    OSSIM

    If ELK isn’t the most popular SIEM, then OSSIM likely wins the crown. The open source version of Alien Vault’s Unified Security Management offering, OSSIM is a framework like Prelude. OSSIM combines its native log storage and correlation capabilities with numerous open source projects to build a complete SIEM.

    The open source projects included in OSSIM include FProbe, Munin, Nagios, NFSen/NFDump, OpenVAS, OSSEC, PRADS, Snort, Suricata and TCPTrack. The inclusion of OpenVAS is of particular interest, as OpenVAS is used both for vulnerability assessment by correlating IDS logs with vulnerability scanner results.

    Like Prelude, the open source OSSIM is not as feature-rich as its commercial sibling. Both solutions work fine for small deployments, but experience significant performance issues at scale, ultimately driving organizations towards the commercial offerings. Log management capabilities in the open source version of OSSIM, for example, are virtually nonexistent.

    Conclusion

    A complete SIEM solution includes the ability to collect information from various data sources, store the data long term, perform analysis on that data and visualize it in useful ways. There are no clear open source winners that deliver all capabilities.

    When selecting an open source SIEM you are either going to have to use feature and performance limited solution designed to drive organizations into the arms of a commercial solution, or you are going to have to combine multiple open source projects to achieve your goals.

    Consider the ELK stack as an example. On its own, the ELK Stack can be a high-quality SIEM solution. Its input filters include public cloud infrastructure monitoring capabilities the other open source solutions can’t match.

    That said, the more dedicated collection and analysis tools, such as OSSEC and Snort, can be far more powerful when dealing with on-premises solutions. These solutions can be combined. OSSEC and Snort can feed the ELK Stack, creating a more complete solution that meets the needs of the majority of organizations.

    Open source SIEM solutions—in whole or in part—are versatile and powerful. They require experience, expertise, and above all time to deploy properly. It is for this reason that commercial offerings dominate the SIEM landscape, even when open source tools lie at the core of those commercial offerings.

    Having 80 percent of your SIEM solution handled for you is better than having to do all of it yourself. Commercial solutions handle installation, basic configuration and provide filters, correlation configurations and visualisation designs for the most common use cases. Don’t underestimate the value of these commercial features: There are a seemingly unlimited number of things to monitor in today’s data centers, and none of us have time to manually configure applications to watch them all.

    — Daniel Berman

  • What It Really Takes to Build Compliant Apps

    What It Really Takes to Build Compliant Apps

    If you search online for “software compliance,” you’ll be met with a seemingly endless lineup of blog posts, how-tos and explainer articles promising to tell you everything you need to know about writing and deploying software in a compliance-friendly manner.

    Some of those are good resources, especially the ones that delve into meeting specific compliance requirements associated with specific regulatory frameworks. (Articles that make generic recommendations such as “secure your data!” are less helpful, but I digress.)

    In this article, I aim to contribute something new to the conversation about software and compliance, especially as it relates to modern, containerized, microservices-based environments. I’m not going to rehash all of the existing content about compliance best practices. Instead, I’d like to offer a new way of thinking about how you actually build compliant applications—by taking a DevOps approach to compliance.

    What does that mean, exactly? Let me explain.

    Why DevOps Compliance?

    I know, when you hear a term like DevOps compliance, your first thought is likely, “Well, there’s another meaningless buzzword.”

    But when I use that term, I’m thinking about much more than marketing hype. I’m referring to the actual practice of using DevOps processes as the basis for building compliance into your applications.

    I’ll explain what that looks like in a moment. For now, let me explain why the concept of DevOps compliance matters.

    For one, this concept drives home the truth that to create compliant applications, you need to make deliberate design decisions and follow specific processes for implementing them. This is what makes the concept of DevOps compliance, as I’m presenting it here, different from typical recommendations for achieving software compliance. Instead of treating compliance as something that you worry about once your application is written (or as a process that lives in its own silo, if you want to describe it in DevOps-y terms), the innovation behind DevOps compliance is to bake the compliance process into the rest of the software delivery pipeline, ensuring that the software that’s created is secure from the beginning of the development process.

    Implementing DevOps Compliance

    What does DevOps compliance look like in practice? How do you actually bake compliance into a CI/CD pipeline?

    Involving Everyone in Compliance

    For starters, you ensure that everyone who plays a role in software delivery understands what compliance means and which specific compliance requirements affect the software they are building. This is not often the case by default. Typically, compliance is something that your lawyers and security team know about, but not something your developers, software testers or IT Ops team members spend much time studying.

    To do DevOps compliance, that has to change. Your engineers need not become compliance experts, but they need visibility into the specific compliance challenges that they must meet. They must also understand how those challenges change—as they frequently do, because compliance frameworks have a tendency to be updated regularly.

    Tracking Compliance Across the CI/CD Pipeline

    Second, achieving DevOps compliance requires implementing processes that allow you to verify and vet the state of compliance at all stages of the software delivery process. When developers are designing new code, they should be thinking about how that code can be compliant. When the QA team is testing the code, they should verify that it meets compliance goals. And when IT Ops deploys the code, it should monitor it to ensure that it is actually fulfilling compliance needs in production.

    A third key process to implement is auditing across the software delivery life cycle. While the precise reporting and auditing requirements of software vary from one compliance framework to another, it’s a best practice to make sure that you are logging and able to report compliance-related data.

    Auditing

    The problem many organizations run into is that they think about the auditing challenge only when software is in production. To do DevOps compliance, you should be baking auditing into all stages of the CI/CD process by collecting data that demonstrates how you are working to meet compliance goals, and that measures your success in achieving them. This practice ensures that if something goes wrong with compliance, you have full visibility into where the issue originated and how to fix it, which are important considerations for meeting compliance challenges successfully.

    Ideally, you’d never make a compliance mistake, but in reality, you probably will sometimes experience oversights. When they happen, it’s much better if you know exactly what went wrong and can quickly develop a plan for fixing it. That not only helps you avoid repeating the same mistake, but it can also help keep regulatory authorities happy. They tend to be more forgiving of compliance errors if you can show proactively (using your own auditing data) that you know what went wrong, and how you are going to fix it.

    Conclusion

    Compliance is not something that most developers or Ops engineers enjoy thinking about. In fact, it’s something that many of them don’t think about at all, and that’s a problem. But as software-related compliance challenges grow increasingly more complex, and as the consequences of non-compliance grow ever greater (both in terms of regulatory fines and a loss of reputation in the eyes of customers), compliance is something that all participants in the CI/CD pipeline should be supporting. They should be doing so at all stages of the software delivery process, and in a way that maximizes visibility into compliance efforts via a clear auditing trail. That’s what DevOps compliance looks like.

    — Sonya Koptyev

  • 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

  • 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: Promoting Innovation at the RSA Conference

    DevOps Chat: Promoting Innovation at the RSA Conference

    RSA Conference is where the world comes to meet Security. For the last 14 years, the Innovation Sandbox Contest was where you could find out what the up and coming companies in security were up to.

    This year RSAC is doing something else in addition. The Launch Pad is where to come to if you have a great idea. You can pitch to VCs, the community and your peers – get great feedback.

    In this chat we speak with Cecilia Marinier of RSAC about Sandbox, Launch Pad and so much more that is RSAC. Listen to the chat, go to RSAC and enjoy.


    Transcript

    Alan Shimel: Hey everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard and you’re listening to another DevOps Chat. Today’s DevOps Chat is gonna focus on well, what for me is my favorite conference of the year, the RSA Conference in San Francisco, which this year is the week of March 4. And one of the great things about RSA conference is there’s so many things going on. I’m happy to be joined actually by someone from the RSA conference team. Cecilia Marinier, Marinier. Cecilia, I hope I didn’t mess that up terribly. My French is … that New York accent just doesn’t work with French. I’m sorry [laughs]. But Cecilia, you there?

    Cecilia Marinier: I am here. Thank you. And you did a great job with my last name. Thank you.

    Shimel: Why don’t you say it right, though, for everyone?

    Marinier: Okay. So my name is Cecilia Marinier.

    Shimel: Marinier. Oh, you can almost taste the French food in the way you even say it. Anyway, I just got back from France, Cecilia and so I appreciate it. But you’re with RSA Conference. Why don’t you give our audience a little bit of background on what your position is and your own journey on how you got here?

    Marinier: Absolutely. Thank you. So I work with the RSA Conference. I joined them about five years ago and I started actually working with just the RSA Conference Innovation Sandbox content having a strong interest in innovation in cyber security. Prior to that, I was working with a small boutique consulting firm that consulted US government clients on security intelligence issues and one of the main focal areas was cyber security, which is what drove my interest into actually joining RSA conference. And tying that together with innovation is just how I got started on this journey and from there, it’s just been a super wonderful ride with RSA conference. Just keep on building out these incredible programs focused on innovation.

    Shimel: Correct. So I’ve had the pleasure of being involved with the innovation sandbox contest now for a number of years. I would say it’s gotta be going on what seven or eight years they’re doing it? Maybe more at RSA already?

    Marinier: Yeah. Actually it’s 14 years.

    Shimel: 14.

    Marinier: This is our 14th year.

    Shimel: Oh my God.

    [Crosstalk]

    Marinier: I know. But it started off under – [laughs] I know. Well, it started off under a different name back in 2005 and then in 2009, it actually changed into the current form, which is the innovation sandbox contest. But there were really incredible company that came through that you might recognize like source buyer and Imperva in those first couple of years so it’s –

    Shimel: I remember those years. And maybe that’s why I said seven or eight years because since they’re using their name, the Sandbox. But in any event, we’re very careful to use the name Innovation Sandbox Contest because we don’t wanna confuse people. Again, there’s so much going on at RSA conference. There’s also the RSA Sandbox where people kinda have hands on experiences with different tools and so forth and security, and cyber security. Correct?

    Marinier: Exactly. The RSA Conference Sandbox actually hosts three sandboxes, plus sands _____ _____ and each sandbox has these hands on activities and it’s in the internet of things. IoT village. It has also ICS village looking at _____ systems and finally, we are – this year, we’re bringing in wireless hacking village too. So it’s a really exciting time for the sandbox in addition to the innovation sandbox contest.

    Shimel: Absolutely. That is exciting. I remember seeing it last year. That’s some great stuff. But when we talk about the Innovation Sandbox Contest _____ _____ for those of you maybe from my DevOps audience or who have not had the pleasure of attending RSA Conference, it really is a showcase for new technology, for new sec companies to get in front of some of the top, top people who are judges for this contest and really show them what you got. Right? And like you said, companies like Imperva and Marty’s _____ source fire and many others have been recognized over the years at the Sandbox Innovation or Innovation Sandbox contest. So it really is great.

    Why don’t, if you can, Cecilia, let’s talk a little bit. What is the process? How do the companies get selected? How is a winner picked? Give our audience a little insight?

    Marinier: Absolutely. So right now is the submission period and right now, any company that is less than five years old and less than $5 million in revenue can apply online for the contest and there’s an application process. You send in a 3 minute video that can be taped in your offices. It doesn’t have to be professionally made. And all those submissions are then sent to the judges and our judges are extraordinarily awesome this year. I’m really proud of the diversity.

    So one of the things that we do when we’re looking at Innovation Sandbox Context to ensure that the company will be successful, is we have all the people who are interested and understand what it takes to make a successful company. So we have our venture capitalist. We have our siso who’s the buyer. We have an entrepreneur, a veteran entrepreneur who this year is actually Shlomo Cramer who has been a –

    Shimel: Who?

    Marinier: Veteran on the stage. Shlomo Cramer from Cato Network and Imperva and Checkpoint. So Shlomo will be our entrepreneur and then we also have a chief strategy officer who’s representing what it’s like to be a buyer inside a large company. So we cover the gamut of what will it take to actually take this to market and I think that’s one of the – why this is always choosing very successful companies. Even most recently, if you look at Phantom which was acquired by Splunk or if you look at Unify ID who won in 2017 and they received good funding right afterwards, it’s a great Launchpad for a lot of different – I shouldn’t say Launchpad. It’s a great place for companies to actually showcase their latest products. The only other caveat is the product has to have come out between December 1st 2017 and December 1st 2018. So we’re looking at those start ups that have launched their product and if they’re ready to go to market, they can apply online for Innovation Sandbox Contest.

    Shimel: Excellent. Excellent, excellent, excellent. I will include the URLs for all that, guys, with the show notes here in the podcast. And Cecilia, I really should chime in in that yeah, there’s been a lot of quote on quote famous companies that won but what I always loved about the sandbox contest was the pure democracy of it. Right? It’s really as open to any company that’s under five years and under $5 million and the three minute limit on the video, they mean three minutes. I, myself, have worked on these videos in the past and I know we’ve word smithed them and talked faster to get as much as we can in on those three minutes as possible but it really is.

    You don’t have to be a blue chip VC-backed company here to invest or to enter and even to win. There’s been companies that weren’t DC backed at the time over the years that have won, if I’m not mistaken.

    Marinier: Yes.

    Shimel: Yep. And I remember – and wound up leading where – it’s hard to draw. It’s a dotted line but it wound up leading to those companies getting funding as a result of winning as well. So it really is. It’s a prestigious thing to win. Now, if someone’s out here listening and say, “Oh, I may go to RSA Conference this year,” and by the way, if you are, there’s some discount codes available on Security Boulevard and devopsy.kinsta.cloud through our RSA Conference partnership, if you are looking to attend. But if you are looking to attend, Cecilia, how can the attendees interact and see what’s going on and participate in Sandbox Innovation Contest?

    Marinier: Well, actually, the conference itself has really made big strides in trying to build an ecosystem around innovation. So in addition to the Innovation Sandbox Contest, which does have a break while the judges is evaluating the companies to chose a winner and the attendees for that particular event can go meet the top 10. There’s kiosks there. But in addition, we’ve created a couple other opportunities for the attendees to see what’s happening in innovation and cyber security and one of those areas is called the early stage expo. And this area has 50 startups this year. We’re up to 50 startups and it also has a small briefing center and yeah, it’s an amazing opportunity. It’s located right next to the sandbox that was talked about earlier and it runs from Tuesday through Thursday so you can check the hours online for that.

    Additionally, if you are an entrepreneur but you’re not quite there yet and you wanna learn a little bit more about how to become an entrepreneur, we have a half day how-to seminar on Monday which covers how to get funding, how to get in front of the busy CISO, how to go to market and the journey of an entrepreneur. So all of these are elements that are tied into what’s going on in innovation itself. And then also, additionally, we have this new event that we’re launching which I’m pretty psyched about which is called RSA Conference Launch Pad. And I’m happy to share more about that with you right now or we can wait and put it on hold and I’ll tell you a little bit later [laughs].

    Shimel: No, no. Go ahead. That cat’s out of the bag. Let’s go.

    Marinier: All righty. So the thing about RSA Conference Innovation Sandbox Contest that we noticed was that we’d had a lot of strong, solid companies that I would almost say later stage startups. What we thought would be really cool and what we saw in some of the submissions that were just in the cusp of getting ready to launch their product but had not quite done so yet and so they didn’t qualify during that year. And what we wanted to do was offer them a different opportunity, which, again, is to get in front of this audience but this time, they’re going just in front of three venture capitalists and there’s three very strong venture capitalists based here in Silicon Valley that their names are gonna be really well-known when you see them.

    And this is kinda more like a “Shark Tank” kind of event where you’ll go and they’ll be pitching in front of the audience and maybe one of these venture capitalists might just put some money towards one of the companies. There will only be three of them. It’s not a winner take all. It’s literally just an opportunity for people to see what are the venture capitalists interested in, what kinda questions are they asking, and then also to kinda get a glimpse into an earlier stage start up. So it’s really fun and exciting and that’s on Tuesday afternoon and that will be a really fun event as well.

    Shimel: Excellent. Excellent. You know what amazes me, Cecilia? So I’ve been in the – we’ve spoke off mic and I’ve been going to RSA Conference since like 2002, 2003 maybe. And what amazes me is I remember back in maybe around 2005 or 2006, I had started something called the Security Bloggers Network. We had our security bloggers meet up every year. This is when blogging about security was first becoming really popular, ’04, ’05. And RSA Conference, actually, was a catalyst and a sponsor of this back then. We’ll be doing it again this year. I think it’s the … I don’t know, 15th or 12th. I forget how many years. We’ve been doing it a long time.

    Anyway, we were talking back then and I remember hearing people say something like, “Do you know there are 600 or 700 security companies in the world? There’s no way the market can support that many …” We didn’t call it cybersecurity. It was InfoSec. “There’s no way the market can support that many InfoSec companies.” And now, we look at RSA Conference today and there’s something like 500 companies or so exhibiting at RSA in that range. And we –

    Marinier: Yeah. There is.

    Shimel: Do you know the number? I don’t.

    Marinier: I believe there are 600 going to be on the floor this year, plus the 50 at early stage expo. So over 600 is what I was –

    Shimel: Well, there you go.

    Marinier: Comfortable saying over 600 for sure [laughs].

    Shimel: Yeah. So there you go. There are more than that just exhibiting at RSA Conference this year so the growth in the market. But to give them something like this early stage expo is really such a leg up because you know what? I’ve been on both sides of this from this divide and it’s not cheap. It’s not cheap going to any conference in San Francisco. It’s not cheap exhibiting at a conference in San Francisco. And I don’t mean to single out San Francisco. It’s not cheap, period, doing conferences. And but in the case of RSA, it very much is a question of, “Well, if you’re not there, people ask why. Are you really a player? Are you serious? How could you not be at the biggest event of the industry?”

    And so giving them a sort of fast track, and quite frankly, a bit of a discount to get your foot in the door, it’s a great thing. So kudos to RSA, to RSA Conference for doing this and I think it’ll be really cool. I encourage people to go check out some of the folks in the Launchpad because that’s where you’ll find _____ _____.

    Marinier: And also, yeah, in that early stage expo area, it is exactly like you said. It’s what we’ve heard from the people who are exhibiting in that area is they love it because the people who come into early stage expo are really interested in learning more about each of the companies and they’ll stop. And the kiosks are not that large but they all have just an interesting background and story and there’s a lot of people that walk through and just really enjoy getting to have that personal attention from the CEO of the company because they’re so – these companies are so small that you’re meeting the CTO. You’re meeting the CEO. So it’s really a cool little area. I really hope that your listeners all get to stop by and check it out.

    Shimel: Absolutely. And just to be clear, usually the expo floor for RSA opens up the Monday night, which I think is March 4th this year.

    Marinier: It is.

    Shimel: Will the innovation area, the Launch Pad area and Sandbox be open Monday?

    Marinier: No. So Innovation Sandbox Contest runs from 1:30 PM to 4:30 PM on Monday, March 4th.

    Shimel: On Monday.

    Marinier: Yes. And it closes and then that’s when we go over to the welcome reception. We encourage people to go over to the welcome reception at the Moscone. We’re actually going to be at the Marriott this year so please come to the Marriott.

    Shimel: Oh, okay.

    Marinier: That’s where we’re gonna be for all the innovation –

    [Crosstalk]

    Shimel: Okay. I didn’t know that. So they are still using Marriott this year. I thought the construction on Moscone was gonna be finished and everything was moving in.

    Marinier: I thought so too and the construction has –

    [Laughter]

    The construction actually has been promised to be done but the area that they were anticipating, the thing that Innovation Sandbox Contest has grown so big that we need to have this size room that can hold 2,000 people and so that’s why we’re there, we’re over at the Marriott this year. And hopefully, in the future, they’ll be able to – it will change and we’ll all be in the same area but the Marriott is really close to Moscone West so I hope –

    Shimel: Oh, no, no, no. It’s right around the corner between Jillian’s. You go Moscone, Jillian’s, and the Marriott. And I should also mention that also Monday starting at 9:00 AM in the morning, I’ll be running for the fifth year, our DevOps Connect DevSecOps days event in Moscone. RSA Conference obviously puts us on and I was lucky. I got moved to Moscone last year, Cecilia. We were like the first people in this beautiful room up in … I guess it’s Moscone North. It’s a brand new section. It’ll be up there and I think it was us and the Cloud Security Alliance. We were right next to each other and …

    Marinier: You’re making me jealous. You’re making me jealous, Alan.

    Shimel: I’m sorry. I don’t wanna rub it in but I was told we’ll have the same room this year. So we start at 9:00 AM. We’ll run through 4:00 PM but there’s plenty of time to run back and forth here from the Marriott to the Moscone. It’s literally a couple of steps.

    Marinier: Yep. It’s very close.

    Shimel: So I encourage everyone to do do both. And then the launch pad is … will run through the whole expo?

    Marinier: The Launchpad is the event on Tuesday with the sharks, with the venture capitalists and then the early stage expo areas opens right after that as Launch Pad closes. As soon as Launch Pad finishes that event, we open the whole space, the Sandbox and the Early Stage Expo. Actually, it’s opened with the Cyber Ops, which is kind of a fun little networking event in addition to opening the space. And then it will be open from 8:00 AM to 4:00 PM on Wednesday and from 8:00 AM to 3:00 PM on Thursday.

    Shimel: Fantastic. Well, Cecilia, when we started, I told you that once we start talking shop, the time just flies. So I’m sorry to say that we’re about out of time. But just man, I’m already really pumped for RSA Conference this year but I always am but I’m really excited for what’s going on with the Sandbox, Innovation Sandbox Contest, the Launchpad, the Startup Showcase. If you’re not moving forward in this business, you’re dying, as they say, right? And RSA Conference continues to move forward in being innovative and getting these new companies a shot at getting their bite at the ring or grabbing the ring or whatever you wanna call it, bite at the apple. So congratulations to you and the team for doing this and thanks for doing it.

    Marinier: Thank you.

    Shimel: And we’re looking forward to it. We’ll be there. We’ll check it out. Maybe we’ll report. There’s a good chance we might be on Broadcast Row over in Moscone West during the week doing some video broadcasting. And if so, maybe we can get you and some of the folks from the Sandbox contest and the showcase in and we can make them movie stars or at least YouTube stars [laughs].

    Marinier: Sounds great. Sounds great.

    Shimel: All righty. Fantastic. Cecilia Marinier. Close?

    Marinier: Excellent. Very good.

    Shimel: I’m getting there, man.

    [Crosstalk]

    A French model on the internet like the commercial says. Anyway, Cecilia, thank you so much for being our guest here on DevOps Chat. Good luck with RSA Conference. It’s coming up in a few months. Hey, Sandbox Contest applications are available if you’re listening. Go do it. And you’re eligible and you think you’ve got a shot here, I would encourage you. But for now, this is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard and you’ve just listened to another DevOps Chat. Have a great day everyone.

    — Alan Shimel

  • 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