Posts

OPNFV

The OPNFV project provides users with open source technology they can use and tailor for their purposes; learn how to get involved.

Over the past several weeks, we have been discussing the Understanding OPNFV book (see links to previous articles below). In this last article in the series, we will look at why you should care about the project and how you can get involved.

OPNFV provides both tangible and intangible benefits to end users. Tangible benefits include those that directly impact business metrics, whereas the intangibles include benefits that speed up the overall NFV transformation journey but are harder to measure. The nature of the OPNFV project, where it primarily focuses on integration and testing of upstream projects and adds carrier-grade features to these upstream projects, can make it difficult to understand these benefits.

To understand this more clearly, let’s go back to the era before OPNFV. Open source projects do not, as a matter of routine, perform integration and testing with other open source projects. So, the burden of taking multiple disparate projects and making the stack work for NFV primarily fell on Communications Service Providers (CSPs), although in some cases vendors shouldered part of the burden. For CSPs or vendors to do the same integration and testing didn’t make sense.

Furthermore, upstream communities are often horizontal in their approach and do not investigate or prioritize requirements for a particular industry vertical. In other words, there was no person or entity driving carrier grade features in many of these same upstream projects. OPNFV was created to fill these gaps.

Tangible and Intangible Benefits

With this background, OPNFV benefits become more clear. Chapter 10 of the book breaks down the tangible and intangible benefits further. Tangible benefits to CSPs include:

  • Faster rollout of new network services
  • Vendor-agnostic platform to onboard and certify VNFs
  • Stack based on best-in-class open source components
  • Reduced vendor lock-in
  • Ability to drive relevant features in upstream projects

Additionally, the OPNFV community operates using DevOps principles and is organized into small, independent and distributed teams. In doing so, OPNFV embodies many of the same practices used by the web giants. CSPs can gain valuable insight into people and process changes required for NFV transformation by engaging with OPNFV. These intangible benefits include insights into:

  • Organizational changes
  • Process changes
  • Technology changes
  • Skillset acquisition

OPNFV is useful not only for CSPs, however; it also provides benefits to vendors (technology providers) and individuals. Vendors can benefit from interoperability testing (directly if their products are open source, or indirectly through private testing or plugfests), and gain insights into carrier-grade requirements and industry needs. Individuals can improve their skills by gaining broad exposure to open source NFV. Additionally, users can learn how to organize their teams and retool their processes for successful NFV transformation.

The primary objective of the OPNFV project is to provide users with open source technology they can use and tailor for their purposes, and the Understanding OPNFV book covers the various aspects to help you get started with and get the most out of OPNFV. The last section of the book also explains how  you might get involved with OPNFV and provides links to additional OPNFV resources.

Want to learn more? You can download the Understanding OPNFV ebook in PDF (in English or Chinese), or order a printed version on Amazon. Or you can check out the previous blogs:

Mauro Carvalho Chehab answers a few questions about his work on the Linux kernel.

According to the recent Linux Kernel Development Report, the Linux operating system runs 90 percent of the public cloud workload, has 62 percent of the embedded market share, and 100 percent of the TOP500 supercomputers. It also runs 82 percent of the world’s smartphones and nine of the top ten public clouds. However, the sustained growth of this open source ecosystem would not be possible without the steady development of the Linux kernel.

In this series, we are highlighting the ongoing work of some Linux kernel contributors. Here, Mauro Carvalho Chehab, Open Source Director at Samsung Research Brazil, answers a few questions about his work on the kernel.

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

I’m responsible for the Open Source efforts at Samsung Research Brazil, as part of Samsung’s Open Source Group. I maintain the media and EDAC (Error Detection and Correction) kernel subsystems.

Linux Foundation: What have you been working on this year?

This year, I did a lot of patches that improves Linux documentation. A lot of them were related to the conversion from the XML-based DocBook docs to a markup language (Restructured Text). Thanks to that, no documents use the legacy document system anymore. I also finally closed the documentation gap at the DVB API, with was out of sync for more than 10 years! I also did several bug fixes at the media subsystem, including the 4.9 breakage of many drivers that were doing DMA via stack.

Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

We should continue our work to support new device drivers and get rid of out of tree stuff. At the media subsystem, we should work to add support for newer TV standards, like ATSC version 3 and to improve support for embedded systems, on both DVB and V4L2 APIs.

Linux Foundation: Why do you contribute to the Linux kernel?

Because it is fun! Seriously, I strongly believe that the innovation process on computer engineering is currently driven by Linux. Working on its kernel has provided me the opportunity of working with great developers and helping to improve the top operating system.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

open source community

Zachary Dupont wrote a letter to his hero Linus Torvalds back in 2014. Here, they catch up on stage at Open Source Summit NA 2017.

The Linux Foundation works through our projects, training and certification programs, events and more to bring people of all backgrounds into open source. We meet a lot of people, but find the drive and enthusiasm of some of our youngest community members to be especially infectious. In the past couple of months, we’ve invited 13-year-old algorithmist and cognitive developer Tanmay Bakshi, 11-year-old hacker and cybersecurity ambassador Reuben Paul, and 15-year-old programmer Keila Banks to speak at Linux Foundation conferences.

In 2014 when he was 12, Zachary Dupont wrote a letter to his hero Linus Torvalds. We arranged for Zach to meet Linus–a visit that helped clinch his love for Linux. This year, Zach came to Open Source Summit in Los Angeles to catch up with Linus and let us know what he’s been up to. He’s kept busy with an internship at SAP and early acceptance to the Computer Networking and Digital Forensics program at the Delaware County Technical School.

The open source community encouraged Zach to pursue his passions. They’ve inspired him, and he plans to give back in the future.

We encourage everyone to find ways to bring more people of all ages into open source. Volunteer your time to teach students or people making mid-career changes how to code, spend time on writing documentation for your open source project so others can get to know it better, or simply take the time to answer beginner questions on message boards. The more people we bring into the community, the stronger we will be in the years ahead.

[vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]1. LinuxCon + ContainerCon + CloudOpen China
Developers, architects, sysadmins, DevOps experts, business leaders, and other professionals gathered in June to discuss open source technology and trends at the first-ever LinuxCon + ContainerCon + CloudOpen (LC3) event in China. At the event, Linus Torvalds spoke about how Linux still surprises and motivates him.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23077″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]2. Toyota Camry Will Feature Automotive Grade Linux
At Automotive Linux Summit in Japan, Dan Cauchy, Executive Director of Automotive Grade Linux (AGL), announced that Toyota has adopted the AGL platform for their next-generation infotainment system.The 2018 Camry will be the first Toyota vehicle on the market with the AGL-based system in the United States.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23078″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]3. Open Source Summit Debuts
As announced at last year’s LinuxCon in Toronto, this annual event hosted by The Linux Foundation is now called Open Source Summit. It combines LinuxCon, ContainerCon, and CloudOpen conferences along with two new conferences: Open Community Conference and Diversity Empowerment Summit.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23079″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]4. Joseph Gordon-Levitt at OS Summit North America
Actor Joseph Gordon-Levitt, founder and director of the online production company HITRECORD, spoke at Open Source Summit in Los Angeles about his experiences with collaborative technologies. Gordon-Levitt shared lessons learned along with a video created through the company.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23080″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]5. Diversity Empowerment Summit
Tameika Reed, founder of Women in Linux, spoke at the Diversity Empowerment Summit in Los Angeles about the need for diversity in all facets of tech, including education, training, conferences, and mentoring. The new event aims to help promote and facilitate an increase in diversity, inclusion, empowerment, and social innovation in the open source community.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23081″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]6. Hyperledger Growth
Hyperledger — the largest open blockchain consortium — now includes 180 diverse organizations and has recently partnered with edX to launch an online MOOC. At Open Source Summit in Los Angeles, Executive Director Brian Behlendorf spoke with theCUBE about the project’s growth and potential to solve important problems.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23082″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]7. Lyft and Uber on Stage at Open Source Summit
At Open Source Summit in Los Angeles, ride-sharing rivals Lyft and Uber appeared on stage to introduce two new projects donated to the Cloud Native Computing Foundation. Chris Lambert, CTO of Lyft (on left), and Yuri Shkuro, Staff Engineer at Uber, introduced the projects, which help CNCF fill some gaps in the landscape of technologies used to adopt a cloud-native computing model.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23083″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]8. Attendee Reception at Paramount Studios
The Open Source Summit North America evening reception for all attendees was held at iconic Paramount Studios in Hollywood. Attendees enjoyed a behind-the-scenes studio tour featuring authentic Paramount movie props and costumes.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23084″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]9. 2017 Linux Kernel Summit and Kernel Development Report
Open source technologists gathered in the city of Prague, Czech Republic in October for Open Source Summit and Embedded Linux Conference Europe. Co-located events included MesosCon Europe, KVM Forum, and Linux Kernel Summit, where The Linux Foundation released the latest Linux Kernel Development Report highlighting some of the dedicated kernel contributors.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23085″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]10. The Next Generation of Open Source Technologists
The Linux Foundation 2017 events aimed to inspire the younger generation with an interest in open source technologies through activities like Kids Day and special keynotes, such as those from 13-year-old algorithmist and cognitive developer Tanmay Bakshi, 11-year-old hacker and cybersecurity ambassador Reuben Paul (pictured here), and 15-year-old programmer and technologist Keila Banks.[/vc_column_text][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][image_with_animation image_url=”23086″ alignment=”” animation=”Fade In” box_shadow=”none” max_width=”100%”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]You can look forward to more exciting events in 2018. Check out the newly released 2018 Events calendar and make plans now to attend or to speak at an upcoming conference.

Speaking proposals are now being accepted for the following 2018 events:

Submit a Proposal[/vc_column_text][/vc_column][/vc_row]

open source culture

Open source involves a culture of understanding change. It’s about evolution as a group, says Mesosphere’s CMO Peter Guagenti.

In the early days of open source, one of the primary goals of the open source community was educating people about the benefits of open source and why they should use it. Today, open source is ubiquitous. Almost everyone is using it. That has created a unique challenge around educating new users about the open source development model and ensuring that open source projects are sustainable.

Peter Guagenti, CMO at Mesosphere, Inc.

Peter Guagenti, the Chief Marketing Officer at Mesosphere, Inc., has comprehensive experience with how open source works, having been involved with several leading open source projects. He has been a coder, but says that he considers himself a hustler. We talked with him about his role at Mesosphere, how to help companies become good open source citizens, and about the role of culture in open source. Here is an edited version of that interview.

The Linux Foundation: What’s the role of a CMO in an open source software company?

Peter Guagenti: The role of a CMO in a software company is fundamentally different from that in any other category.  We have a really interesting role in marketing and technology, and it’s one of education and guidance. There used to be a place 20 years ago where, as a marketer, you would come up with a simple pithy message and buy a bunch of advertising and people would believe it.

That’s not true anymore. Now we have to position ourselves alongside the architectures and the thought leadership that our customers are interested in to prove our value.

The Linux Foundation: Can you explain more about this approach?

Guagenti: I love that instead of focusing on marketing taglines, you really have to know the technology so customers have the confidence that they will get the support we promise. Since this space is changing so quickly, we spend probably half our time simply on educating and informing about the market and the challenges that customers face.

I don’t think about talking about DCOS, for example; I think about how connected cars are really important but nobody really knows how to build them. We serve six of the largest car makers in the world. So getting them to talk about how they’re approaching this problem — what they think about Edge computing, what they think about computing in the car, or what they think about data and moving that data around. These are the real exciting things.

The Linux Foundation: Can you talk about other work you have done in open source?

Guagenti:  I’m a long-time open source advocate. I’ve been in open source for over 10 years. I built an open source services practice in a large digital agency called Razorfish when I was at a client services there. I’ve spent time at three open source companies: Acquia, which is in the Drupal open source project; Nginx, which is the world’s most popular web server and application delivery controller; and now I am at Mesosphere, the container company.

The Linux Foundation: Open source has become the de facto software development model — almost everyone is consuming open source these days. That creates a new challenge as many new consumers don’t fully understand how open source works, which can lead to problems like not being part of the ecosystem and creating technical debt. Have you come across this problem?

Guagenti: Open source has evolved dramatically over the past 20 years. I would argue 10 years ago you were crazy if you were a Fortune 500 company and you were the CIO and said I’m going to integrate open source everywhere. But now open source is the default. I’ve worked in large state and national governments around the world. I’ve worked in the Fortune 500, and they all have adopted open source. But how they adopt open source successfully is different. If you look company by company, if you look at projects, there is a difference.

There are community-driven models, there are corporate-driven models, and there are things in between where you see things like Kubernetes, where you’ve multiple companies contributing at scale. There is a great mix, but companies don’t always know how to make the best use of that. It becomes critical for them to find the right enterprise that helps them understand how to use and deploy it. More important than that is to help them ensure they are making good decisions with that software and driving the roadmap forward by contributing or at least by being a voice in that.

We take for granted that open source exists, but open source requires involvement—either contribution of code or cash—to keep those projects healthy. We are at a point where open source has been around long enough that we have seen early open source projects just die because they didn’t have core maintainers able to earn a salary.

I was told that every great technology company needs a hacker and a hustler. I was a good coder early on, but I wasn’t great. I’m more of a hustler. I loved being able to see businesses build around open source and then have have that really be the heart of a healthy ecosystem where everyone is able to benefit from that code.

The Linux Foundation: What role does culture play in open source adoption?

Guagenti: It matters. Look at the digital transformation that we have been going through for the last 20 years. Look at the companies that have done it best. You will notice that the old stalwarts have now reinvented themselves in a meaningful way. They are continuing to evolve with the time and are competing effectively. They had a culture where they could embrace and accept a lot of these things.  

If you look at hiring the great technology talent, what’s the number one thing great technology talent expects? They want to work with the tools they want to use. They want to do it in a way that fits their pattern of behavior, their pattern of building these things. It’s not the money, it’s not the stock options, it’s not the fancy work. It’s about the kind of work I want to do everyday and and the way I want to do it.  

I work with some of the largest banks, I work with some of the largest government entities. What I have noticed, with some of the most successful ones, is that they have a culture internally where they understand this stuff. They understand what it means to not just use open source but to be a part of an open source community. Sometimes you do run into hurdles. I work with a lot of large companies that are either not comfortable contributing code back or just simply don’t feel they have the time to do it. But they do their bit in a different way; they may do things like contribute  financially to projects, send people to to events, or actually go and tell their story.

That’s what we do a lot at Mesosphere. Since this space is changing, we love having our largest customers talking about what they’re doing with open source. Their culture matters because it’s not just the culture of open source and using open source. It’s a culture of innovation. It’s a culture of understanding change.  And that’s what open source is all about. It’s about evolution as a group.

Learn more about best practices for sustainable open source in the free Open Source Guides for the Enterprise from The Linux Foundation.

A guest blog post by Mike Goodwin.

What is threat modeling?

Application threat modeling is a structured approach to identifying ways that an adversary might try to attack an application and then designing mitigations to prevent, detect or reduce the impact of those attacks. The description of an application’s threat model is identified as one of the criteria for the Linux CII Best Practises Silver badge.

Why threat modeling?

It is well established that defense-in-depth is a key principle for network security and the same is true for application security. But although most application developers will intuitively understand this as a concept, it can be hard to put it into practice. After many years and sleepless nights, worrying and fretting about application security, one thing I have learned is that threat modeling is an exceptionally powerful technique for building defense-in-depth into an application design. This is what first attracted me to threat modeling. It is also great for identifying security flaws at design time where they are cheap and easy to correct. These kinds of flaws are often subtle and hard to detect by traditional testing approaches, especially if they are buried in the innards of your application.

Three stages of threat modeling

There are several ways of doing threat modeling ranging from formal methodologies with nice acronyms (e.g. PASTA) through card games (e.g. OWASP Cornucopia) to informal whiteboard sessions. Generally though, the technique has three core stages:

Decompose your application – This is almost always done using some kind of diagram. I have seen successful threat modeling done using many types of diagrams from UML sequence diagrams to informal architecture sketches. Whatever format you choose, it is important that the diagram shows how different internal components of your application and external users/systems interact to deliver its functionality. My preferred type of diagram is a Data Flow Diagram with trust boundaries:

Identify threats – In this stage, the threat modeling team ask questions about the component parts of the application and (very importantly) the interactions or data flows between them to guess how someone might try to attack it. The answers to these questions are the threats. Typical questions and resulting threats are:

Question Threat
What assumptions is this process making about incoming data? What if they are wrong? An attacker could send a request pretending to be another person and access that person’s data.
What could an attacker do to this message queue? An attacker could place a poison message on the queue causing the receiving process to crash.
Where might an attacker tamper with the data in the application? An attacker could modify an account number in the database to divert payment to their own account.

Design mitigations – Once some threats have been identified the team designs ways to block, avoid or minimize the threats. Some threats may have more than one mitigation. Some mitigations might be preventative and some might be detective. The team could choose to accept some low-risk threats without mitigations. Of course, some mitigations imply design changes, so the threat model diagram might have to be revisited.

Threat Mitigation
An attacker could send a request pretending to be another person and access that person’s data. Identify the requestor using a session cookie and apply authorization logic.
An attacker could place a poison message on the queue causing the receiving process to crash. Digitally sign message on the queue and validate their signature before processing.
Maintain a retry count on message and discard them after three retries.
An attacker could modify an account number in the database to divert payment to their own account. Preventative: Restrict access to the database using a firewall.
Detective: Log all changes to bank account numbers and audit the changes.

OWASP Threat Dragon

Threat modeling can be usefully done with a pen, whiteboard and one or more security-aware people who understand how their application is built, and this is MUCH better than not threat modeling at all. However, to do it effectively with multiple people and multiple project iterations you need a tool. Commercial tools are available, and Microsoft provides a free tool for Windows only, but established, free, open-source, cross-platform tools are non-existent. OWASP Threat Dragon aims to fill this gap. The aims of the project are:

  • Great UX – Using Threat Dragon should be simple, engaging and fun
  • A powerful threat/mitigation rule engine – This will lower the barrier to entry for teams and encourage non-specialists to contribute
  • Integration with other development lifecycle tools – This will ensure that models slot easily into the developer workflows and remain relevant as the project evolves
  • To always be free, open-source (like all OWASP projects) and cross-platform. The full source code is available on GitHub

The tool comes in two variants:

End-user documentation is available for both variants and, most importantly, it has a cute logo called Cupcakes…

Threat Dragon is an OWASP Incubator Project – so it is still early stage but it can already support effective threat modeling. The near-term roadmap for the tool is to:

  • Achieve a Linux CII Best Practices badge for the project
  • Implement the threat/mitigation rule engine
  • Continue to evolve the usability of the tool based on real-world feedback from users
  • Establish a sustainable hosting model for the web application

If you want to harden your application designs you should definitely give threat modeling a try. If you want a tool to help you, try OWASP Threat Dragon! All feedback, comments, issue reports and pull requests are very welcome.

About the author: Mike Goodwin is a full-time security professional at the Sage Group where he leads the team responsible for product security. Most of his spare time is spent working on Threat Dragon or co-leading his local OWASP chapter.

This article originally appeared on the Core Infrastructure Initiative website.

The Linux kernel is the lowest level of software running on a Linux system. It manages the hardware, runs user programs, and maintains the overall security and integrity of the whole system, according to the recent Linux Kernel Development Report. It is also the result of one of the largest cooperative software projects ever attempted, with some 15,600 individual developers from more than 1,400 different companies contributing to the kernel since 2005.

Linux kernel developer Arnd Bergmann

The report, released by The Linux Foundation, outlines the development process and highlights the ongoing work of some of these contributors. In this article, Arnd Bergmann of Linaro answers a few questions about his work on the kernel.

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Arnd Bergmann: I co-maintain the arm-soc kernel tree together with Olof Johansson. This is where all the platform-specific changes for ARM processors and SoCs (both 32-bit and 64-bit) get merged. This is one of the larger subsystems in the kernel, and it interacts with most driver subsystems.

I also maintain a couple of smaller things in the kernel. In particular, I look after new CPU architectures getting merged into the kernel and the associated include/asm-generic/ directory. One of my long-term projects is to fix the time_t overflow in the kernel, which will cause 32-bit code to fail in the year 2038.

Linux Foundation: What have you been working on this year?

Bergmann: Aside from my maintainer work, I have spent a lot of time during the last year on fixing hundreds of smaller bugs that lead to build failures or warnings. I started doing a lot of build-testing as a way to improve the quality of contributions I merge into the kernel from other people, but this has now turned into a separate effort to get all random configurations to build cleanly.

Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Bergmann: I hope we can get the y2038 cleanup work to the point of actually being able to build a kernel with no 32-bit time_t users. For this, we still need help from additional developers cleaning up various areas of the kernel.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

This article explains how to walk through, measure, and define strategies collaboratively in an open source community.

“If you don’t know where you are going, you’ll end up someplace else.” Yogi Berra

Open source projects are generally started as a way to scratch one’s itch and frankly that’s one of its greatest attributes. Getting code down provides a tangible method to express an idea, showcase a need, and solve a problem. It avoids over thinking and getting a project stuck in analysis-paralysis, letting the project pragmatically solve the problem at hand.

Next, a project starts to scale up and gets many varied users and contributions, with plenty of opinions along the way. That leads to the next big challenge how does a project start to build a strategic vision? In this article, I’ll describe how to walk through, measure, and define strategies collaboratively, in a community.

Strategy may seem like a buzzword of the corporate world rather something that an open source community would embrace, so I suggest stripping away the negative actions that are sometimes associated with this word (e.g., staff reductions, discontinuations, office closures). Strategy done right isn’t a tool to justify unfortunate actions but to help show focus and where each community member can contribute.

A good application of strategy achieves the following:

  • Why the project exists?
  • What the project looks to achieve?
  • What is the ideal end state for a project is.

The key to success is answering these questions as simply as possible, with consensus from your community. Let’s look at some ways to do this.

Setting a mission and vision

Efforts and courage are not enough without purpose and direction.” John F. Kennedy

All strategic planning starts off with setting a course for where the project wants to go. The two tools used here are Mission and Vision. They are complementary terms, describing both the reason a project exists (mission) and the ideal end state for a project (vision).

A great way to start this exercise with the intent of driving consensus is by asking each key community member the following questions:

  • What drove you to join and/or contribute the project?
  • How do you define success for your participation?

In a company, you’d ask your customers these questions usually. But in open source projects, the customers are the project participants and their time investment is what makes the project a success.

Driving consensus means capturing the answers to these questions and looking for themes across them. At R Consortium, for example, I created a shared doc for the board to review each member’s answers to the above questions, and followed up with a meeting to review for specific themes that came from those insights.

Building a mission flows really well from this exercise. The key thing is to keep the wording of your mission short and concise. Open Mainframe Project has done this really well. Here’s their mission:

Build community and adoption of Open Source on the mainframe by:

  • Eliminating barriers to Open Source adoption on the mainframe
  • Demonstrating value of the mainframe on technical and business levels
  • Strengthening collaboration points and resources for the community to thrive

At 40 words, it passes the key eye tests of a good mission statement; it’s clear, concise, and demonstrates the useful value the project aims for.

The next stage is to reflect on the mission statement and ask yourself this question: What is the ideal outcome if the project accomplishes its mission? That can be a tough one to tackle. Open Mainframe Project put together its vision really well:

Linux on the Mainframe as the standard for enterprise class systems and applications.

You could read that as a BHAG, but it’s really more of a vision, because it describes a future state that is what would be created by the mission being fully accomplished. It also hits the key pieces to an effective vision it’s only 13 words, inspirational, clear, memorable, and concise.

Mission and vision add clarity on the who, what, why, and how for your project. But, how do you set a course for getting there?

Goals, Objectives, Actions, and Results

“I don’t focus on what I’m up against. I focus on my goals and I try to ignore the rest.” Venus Williams

Looking at a mission and vision can get overwhelming, so breaking them down into smaller chunks can help the project determine how to get started. This also helps prioritize actions, either by importance or by opportunity. Most importantly, this step gives you guidance on what things to focus on for a period of time, and which to put off.

There are lots of methods of time bound planning, but the method I think works the best for projects is what I’ve dubbed the GOAR method. It’s an acronym that stands for:

  • Goals define what the project is striving for and likely would align and support the mission. Examples might be “Grow a diverse contributor base” or “Become the leading project for X.” Goals are aspirational and set direction.
  • Objectives show how you measure a goal’s completion, and should be clear and measurable. You might also have multiple objectives to measure the completion of a goal. For example, the goal “Grow a diverse contributor base” might have objectives such as “Have X total contributors monthly” and “Have contributors representing Y different organizations.”
  • Actions are what the project plans to do to complete an objective. This is where you get tactical on exactly what needs done. For example, the objective “Have contributors representing Y different organizations” would like have actions of reaching out to interested organizations using the project, having existing contributors mentor new mentors, and providing incentives for first time contributors.
  • Results come along the way, showing progress both positive and negative from the actions.

You can put these into a table like this:

Goals Objectives Actions Results
Grow a diverse contributor base     Have X total contributors monthly
  • Existing contributors mentor new mentors
  • Providing incentives for first time contributors
Have contributors representing Y different organizations
  • Reach out to interested organizations using the project

In large organizations, monthly or quarterly goals and objectives often make sense; however, on open source projects, these time frames are unrealistic. Six- even 12-month tracking allows the project leadership to focus on driving efforts at a high level by nurturing the community along.

The end result is a rubric that provides clear vision on where the project is going. It also lets community members more easily find ways to contribute. For example, your project may include someone who knows a few organizations using the project this person could help introduce those developers to the codebase and guide them through their first commit.

What happens if the project doesn’t hit the goals?

“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas A. Edison

Figuring out what is within the capability of an organization — whether Fortune 500 or a small open source project — is hard. And, sometimes the expectations or market conditions change along the way. Does that make the strategy planning process a failure? Absolutely not!

Instead, you can use this experience as a way to better understand your project’s velocity, its impact, and its community, and perhaps as a way to prioritize what is important and what’s not.

An important step in using open source code effectively is setting explicit guidelines to be followed.

Open source programs at organizations of all sizes are fueling innovation, and many program leaders are quickly learning that weaving open source code into projects — and creating new projects — require informed guidelines and best practices. Organizations are often leveraging existing open source code to build their own commercial products and services, and contributing back to projects.

However, diving in and using open source code without an understanding of everything from legal risks to best development practices is perilous. Approaching open source code usage without best practices in place can also tarnish an organization’s reputation. That’s where the free, new Using Open Source Code guide comes in. It can help you craft and codify a comprehensive strategy.

One of the most important steps in using open source code effectively within your program is to set explicit guidelines to be followed, which are often summarized in a strategy document. What if code comes into one of your projects from a project with a different licensing setup? What acceptance, rejection, and exception policies should developers follow? What is your organization’s overall stance toward open source development?

These are all among the questions that need concrete answers as you codify your strategy, and there are more questions involving the ecosystem that applies to using open source code. How are APIs documented? Have you laid out a Contributor Licensing Agreement that everyone can use? Have you picked the right license for your project? Your strategy document should be specific about best practices, APIs and more.

“A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences,” notes Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research America.

Creating a Policy

As the guide notes, creating a strategy document featuring best practices does not need to be complicated. A good open source usage policy includes six simple rules:

  • Engineers must receive approval from the OSRB before integrating any open source code in a product.
  • Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
  • All software must be audited and reviewed, including all proprietary software components.
  • Products must fulfill open source licensing obligations prior to customer receipt.
  • Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
  • All changed components must go through the approval process.

Importantly, the guide also notes the importance of effective code review practices. “If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely,” Haddad emphasizes.

Additionally, Haddad, advises that circumspect code usage and compliance practices must be ongoing. “It’s important to remember that open source compliance doesn’t stop with version 1.0,” he said.

The Using Open Source Code guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave open components into your open source projects. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

These guides were produced based on expertise from open source leaders. Check out the guides and stay tuned for our continuing coverage.

Also, don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

A Free Guide to Participating in Open Source Communities

Read about featured Linux kernel developers in the 2017 Linux Kernel Development Report.

The recent Linux Kernel Development Report released by The Linux Foundation, included information about several featured Linux kernel developers. According to the report, roughly 15,600 developers from more than 1,400 companies have contributed to the Linux kernel since 2005, when the adoption of Git made detailed tracking possible. Over the next several weeks, we will be highlighting some specific Linux kernel developers who agreed to answer a few questions about what they do and why they contribute to the kernel.

Linux kernel developer

Laura Abbott, a Fedora Kernel Engineer at Red Hat

In this article, we feature Laura Abbott, a Fedora Kernel Engineer at Red Hat.

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Laura Abbott: My full-time job is working as one of two maintainers for the Fedora kernels. This means I push out kernel releases and fix/shepherd bugs. Outside of that role, I maintain the Ion memory management framework and do occasional work on arm/arm64 and KSPP (kernel hardening).

The Linux Foundation: What have you been working on this year?

Abbott: I did some major reworking on Ion this year and ripped out a lot of code (everyone’s favorite type of patch!). Hopefully, I’ll be able to report that Ion is out of staging in the next kernel report. Apart from that, I’ve spent a lot of time testing and reviewing patches for kernel hardening.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Abbott: As a general theme, there needs to be a focus on scaling the community. There’s always an ongoing discussion about how to attract new developers and there’s been a recent focus on how to grow contributors into maintainers. There’s still a lot of ‘tribal knowledge’ in pretty much every area which makes things difficult for everyone. I’d like to see the kernel community continue to make processes easier for new and existing developers. I’d also like to see the discussions about building an inclusive community continue.

The Linux Foundation: Why do you contribute to the Linux kernel?

Abbott: I’ve always found low-level systems fascinating and enjoy seeing how all the pieces work together. There’s always something new to learn about in the kernel, and I find the work challenging.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.