Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Cyber Sharing is Caring

One of the biggest challenges I faced while operating a community at a major cybersecurity firm was getting people to share the great stuff they wrote, especially code, scripts or non-product tools. Cybersecurity professionals are more sensitive to the risks posed by sharing information, and often the response is to not openly share.

That's not to say they aren't sharing - they are, but all through email and private channels, rather than openly in your knowledge base or community.

It's simpler to get people to share internally, where customers and partners cannot hold them accountable for their work. But the default state is sharing content through email, which is difficult to search and the history isn't accessible to newcomers. You can drive behavioral changes by writing up the answer in the internal knowledge base or community and sending the link as a response. Coach your key collaborators and team leaders to do this, and eventually it becomes the norm.

It’s more difficult to get external sharing started. Your website or community terms of service should already outline expectations of content use and support for all members, employees included. Yet, your technical contributors may still not feel comfortable sharing externally, especially after a tech giant fired a couple of engineers for their Def Con talk.


It may feel counter-intuitive, but defining a policy for your internal audience may actually encourage them to share scripts and code with your customers and partners. This policy should include clear definitions or descriptions of:

  • Official product:  Include branding, expectations of support and avenues of delivery
  • Volunteer contributions:  You may need to differentiate between code that augments existing products (i.e., scripts that automate functionality) and code that replaces product functionality (i.e., an alternate interface built through the API) or acts as a stand-alone application (i.e., an open source application that doesn't rely on the core product line to function); you may need to enable a structure, either formal or volunteer, for code review
  • Third Party submissions or links:  Content made by anyone other than the company or its employees/contractors that is not hosted on delivery platforms owned, operated, or sponsored by the company.

You may need to define whether open source or other code content created by employees during their employment but hosted/housed in non-company repositories are treated as volunteer contributions or as Third Party. In Figure 1 below, I split the Volunteer contributions into two categories based in part on where the company published their content; your outline may be simpler. Customize Figure 1 to create a synopsis of the points to cover in writing your policy.

Figure 1:  Description of Types of Code Shared by a Company and its Employees

Official Product

Volunteer Contributions to Product

Volunteer Tools & Applications

Third Party Code, Tools or Applications

Author/
Creator

Created by Company through standard engineering/product processes

Code, scripts, tools or applications created by an employee outside the normal engineering/product process

Any code not created by the company or a current employee

Code Function

Provides activities or services as defined by product management or legal contract with the customer

Augments, enhances, relies on, or provides examples for corporate product(s)

Provides alternatives to or stands separate from corporate product(s)

Not determined by company, but generally helpful to audience in some way

Expectation of Support

Company supported

Individual or crowdsourced support; no company support

Not determined by company; no company support

Expectation of Use

Defined by terms of use or legal contract

End-user can review or inspect code, and copy, modify, or otherwise use code as they deem fit

A license or permission is required to review, copy, modify or use code

Not determined by company

Delivery

Formal delivery through established corporate or product channels

Informal distribution by author through community or knowledge platform

Informal distribution through community or knowledge base, or formal distribution by company as freeware/open source

Not determined by company

Code Review

Standard Engineering or Support QA Processes

Informal peer review
- Okay to share externally with caveats

Structured peer review or corporate code review

- Review before sharing externally

Not required

Licensing

Defined by corporate legal team

Covered by website or community Terms of Service

Determined by author and/or corporate legal team

Covered by website or community Terms of Service

Once you’ve written your code-sharing policy, you can work sharing code into your knowledge flow or business processes; Figure 2, below, is a very simple example.

With a clearly defined policy and knowledge flow, your teams should feel more comfortable sharing the non-product work they do with their peers, partners and customers. Remember, however, that your policy and knowledge flow need to work with your website, community or knowledge base Terms of Use and be clearly promoted by your community, knowledge base or website as an informal, unofficial, or unsupported content.


Collaboration & Communication Strategist Carlota Sage uses her love of technology and language to help information security companies communicate and collaborate better. When not making the technical world a better place, she makes jewelry, feeds people waffles, or destroys/rebuilds old Mazdas.


What’s Hot on Infosecurity Magazine?