All posts by admin

Shadow Engineering

Do you allow a supplier’s goods and services to be acquired and used by your employees without the approval of your management? Certainly not any more. You’ve probably spent years applying better governance around the acquisitions made by Shadow IT.

However, even before the emergence of shadow IT, your engineers have been making acquisitions from ungoverned suppliers: open source software authors.

Shadow IT mostly acquires compute and storage resources for internal use, but “shadow engineering” has been exposing your customers to ungoverned intellectual property by using open source software in your products.

Even though there are no subscription, licensing, or maintenance fees charged by these authors, their effects on your products are significant.

Just as shadow IT has helped organizations be more efficient and elastic, shadow engineering has done the same, but you must better govern what shadow engineering is acquiring.

PII and Business Confidential Information (BCI)

Not all Business Confidential Information (BCI) supplied to you is PII.

Many customers blur the distinction between BCI and PII, in belief (or hope) that their BCI should be protected by the same laws that protect PII. However, data privacy laws only protect the identity of people.

BCI is protected, but by business-to-business agreements like NDAs, license agreements, partner agreements, etc.

So when handling information, make sure you know what information is governed by data privacy laws, business-to-business agreements, or both.

Can brand categorization inspire SCA innovation?

Can the creation of a brand category inspire the expansion of existing products and motivate new entrants ?

Yes, this is what can happen with Software Composition Analysis (SCA).

Prior to 2014, Black Duck and Palamida were helping their customers comply with the terms of the licenses that covered the open source they used.

Enter the Heartbleed security vulnerability in open source, and those vendors added reporting of previously disclosed security vulnerabilities in open source. This was an opportunistic leap forward.

Then came the marketing experts. They created the Software Composition Analysis category and now there is a bold direction to inspire innovation.

Yes, open source licenses and security vulnerabilities in open source are still important, but all levels of the software supply chain should care about all the non-functional requirements (NFRs) of software they get from all suppliers.

Whose software to analyze

A Procurement team (with a capital P, not just the finance team) should analyze the composition of software they source from any supplier: commercial software vendors, partners, outsourcers, acquired companies, other divisions and groups within their own company, and (yes) open source authors too.

What software NFRs to analyze

Software can be flawed in many ways: non-compliance to open source license terms and existence of previously disclosed security vulnerabilities are only two of them. When a company develops its own software (either for its own use or for the use of others), it analyzes many NFRs of that software. Since procured software is intended to be an efficient time and cost replacement for in-house developed software, the same analysis should be applied to procured software. A Procurement team should analyze all of the following NFRs of the software they source:

  • Quality
  • Maintainability
  • Scalability
  • Extensibility
  • Portability
  • Compatibility
  • Reusability
  • Usability
  • Accessibility (by those with disabilities)
  • Exportability (based on distribution and use of cryptography)
  • Vulnerability (previously undiscovered, analogous to anomaly-based IDSs)
  • Vulnerability (previously disclosed, analogous to signature-based IDSs)
  • Licensability

Granted, in-house developed software doesn’t always meet every one of these NFRs, but the Procurement team should acknowledge more than just the final two on this list.

The marketers who created the Software Composition Analysis category have pointed the way as a challenge to existing and new SCA product providers to create products and services that analyze many more NFRs.

Continue reading Can brand categorization inspire SCA innovation?

Beware of public Wi-Fi

Because of the mobile equipment you use, the scope of your workspace increases beyond your office.

I’ll walk you through a normal business trip and your re-entry back into your personal life…

Let’s start with you at your office on a Thursday morning; your phone, tablet, and/or laptop are connected to either your corporate wired or wireless network:

  • You get on the train to the airport and connect to the train’s Wi-Fi
  • At the airport terminal and then on the plane you connect to each of their Wi-Fi networks
  • Your taxi or Uber on the way to the hotel doesn’t have Wi-Fi, so your mobile phone is connected to 4G LTE, but a 4G LTE network is NOT a private network segment, it is one shared with other subscribers of (for example) Verizon
  • At the hotel that night, you’re on their network
  • Next morning, you do some pre-meeting preparation at a Starbucks while on their Wi-Fi
  • During your customer meeting you’re on their network
  • Because you need to do some work on your laptop in the taxi on the way back to the airport, your laptop is connected via your AirCard, but AirCards use 4G LTE data connections like mobile phones and so it is NOT a private network
  • When you’re back home Friday night, you connect to your home network
  • Saturday you watch the game at a relatives’ house and connect to their Wi-Fi
  • Sunday you go the gym, and connect to their network

Before, during and after your trip, in all these contexts, you are sending and receiving confidential information over a public network.

So what? You do this all the time and it’s great that you have instant access to information. The problem is that hackers on those public networks can observe your behavior unless you protect yourself with VPN.

VPN stands for Virtual Private Network and it is not the same thing as a firewall, you have to log into a VPN. Businesses usually host a VPN for their mobile workforce and VPNs can be subscribed to by consumers.

Before I detail the benefits of using VPN, here is the information that is potentially visible to others connected to the same network as you:

  • The URLs of web pages you visit in a browser and the URLs of web pages visited behind-the-scenes as you use mobile apps and client applications
  • Web form data you enter… some web pages you visit, like news and Wikipedia articles, respond with static content that is not influenced just because you visit those pages. However, a lot of web pages you visit give you the opportunity to send them form data and tailor the content with which they respond
  • The static page content or the page’s response to your form data

Here is what is visible and what is hidden:

Effect of using VPN
VPN enabledVPN enabledVPN not enabledVPN not enabled
HTTPS pageHTTP pageHTTPS pageHTTP page
siteHiddenHiddenVisibleVisible
form dataHiddenHiddenHiddenVisible
responseHiddenHiddenHiddenVisible

Without VPN enabled, the situation gets complicated. It depends upon whether the page’s owner servers you the page via HTTPS or HTTP (the “S” in HTTPS stands for “secure”). I’ll show you some examples in a second, but even if the page you visit is served to you via HTTPS, without VPN enabled, the fact that you are visiting that page is visible to others connected to the same network as you.

and when you visit a page served to you via HTTP, without VPN being enabled, everything is visible.

Services which believe they are processing your confidential information often use HTTPS to protect you, which is good. However, a service’s idea of what information is confidential to you and your idea of what is confidential might be different. Therefore, avoid this confusion by enabling VPN when doing confidential network activity while connected to a public network.

Here are examples of pages served only via HTTP, meaning that without VPN the form data I send and the response I receive is visible to anyone else on my same network:

So the next time you connect your mobile device to a public network, think about that unseen person in an another room at your same hotel, your roommate at home, your brother-in-law in his basement while you’re visiting your sister, your kids’ friends during a sleep-over, and the AirBnB renter in your spare room.

However, when you use that public network to connect to a VPN server, all that information that the hacker was able to see is now hidden from them, you’re connected to the VPN network and your access to the internet is then made from the VPN network, not from the public network.

 

Practical proprietary and confidential information handling

Information is the most valuable asset you possess in today’s business economy.

Two adjectives are consistently used when talking about business information: proprietary and confidential

Proprietary information is about ownership of the information. For example, information proprietary to you is information owned by you and information proprietary to a customer/prospect/partner or supplier is owned by that respective entity.

So calling information “proprietary information” tells you that is owned by someone (it’s not public), but doesn’t tell you who owns it. You would think that would matter to how you handle proprietary information, but it doesn’t.

You have an obligation to prospects/customers/partners and suppliers to be just as diligent with how you handle information proprietary to them as you have with information proprietary to you.

The second adjective applied to business information is confidential. Confidential means that there are some restrictions on how that information can be accessed or distributed.

As with any property, the owner defines the rules by which the property can be used by others. Therefore, with proprietary information, the owner defines who can access or distribute the information, what information can they access or distribute, where can they access or distribute it, when can they access or distribute, and how can they access or distribute it.

You can imagine that the information owner can place any combination of crazy restrictions on its access. However, to make control of information practical in a business context, information owners define a small number of information confidentiality levels (or information classifications) and describe the access and distribution rules for each level. The simplest classification is two levels: non-confidential and confidential. However, some companies define four or five levels of confidentiality.

In earlier times, businesses primarily distributed information on paper, and stamped the word “confidential” on any document of that classification.

In our modern sharing culture created by the internet, information is so easy to create, distribute, and re-redistribute, owners often forget to mark confidential information as such.

Marking something as confidential is as simple as prefacing the information with the word “confidential” and you should do this. However, just marking a document as confidential does not detail the restrictions around its access or distribution.

Here are practical guidelines on how to handle confidential information you create, you have access to, or you receive. These guidelines are consistent with different NDAs and confidentiality agreements, but do not supersede the requirements specified in a particular agreement:

  • Only use confidential information for its stated purpose
  • Only disclose confidential information to parties affiliated with its stated purpose
  • If the confidential information is proprietary to another party, delete the information upon that party’s request or after it has fulfilled its stated purpose

For example, just because you have an NDA with another party, that does not mean you can give them all of your company’s confidential information, unless that is required to meet the stated purpose.

To abide by the above rules, you need to understand the purpose for the confidentiality of information you possess (or to communicate the purpose if you are the author), and understand who is, and who is not, affiliated with the stated purpose.

If you feel that the restrictions around the information need to be clarified beyond the general guidelines listed above, to avoid doubt in the minds of the recipients, preface the information with your unique restrictions or state the purpose for its confidentiality.

 

Practical guide to data privacy

The laws defining Personally Identifiable Information, and how PII can be controlled and processed are different in different countries, states, and provinces… and unfortunately, there is not much legal precedence for how these laws are to be interpreted.

When handling PII originating from a specific jurisdiction, the laws of that jurisdiction and the advice of legal counsel take precedence over what is written here, but since you continually handle PII and there is no single clear set of laws, here is a practical guide for how you should define, control, and process PII.

So what is PII?

Regular PII includes contact information, sensitive PII associates that contact information with attributes like medical condition, financial account information, sexual orientation, religious or political views, etc.

Responsibilities for data privacy are not because of business relationships. Even if one of your customer’s purchasing department or legal department doesn’t show concern over how you handle the PII of their employees, laws require you to accept the same data privacy responsibilities for their employees as companies who show greater concern. This is the case even if the customer says otherwise; for example, if a customer says it is OK to use their employees’ PII in a product demo, data privacy laws say it is NOT OK unless it is done legally.

So how can you legally process PII?

If you follow all these requirements, you will satisfy many jurisdictional requirements:

  • You must state to the individual:
    • what PII you intend to collect about the them
    • why your are collecting their PII
    • what you will do with their PII (this is also known as the stated purpose)
  • Before collecting the PII, you must receive explicit consent from the individual to do so; that is, you must assume the individual will not allow the collection, and only collect if they allow it; not the other way around
  • Once collected, you and all of your affiliates must process the PII only for the stated purpose
  • When the stated purpose has been completed, you and your affiliates must delete the PII
  • Upon request from the individual, you and your affiliates must correct or delete the PII
  • You must encrypt PII in transit (that is, when it is transferred)
  • If the PII is sensitive, you must also encrypt it at rest (that is, when it is stored)

Some jurisdictions like the EU, Canada, and the state of Massachusetts are particularly concerned about the PII of their citizens, but even more concerned when that PII is transferred outside of their jurisdiction. You usually have to provide citizens from these jurisdictions additional assurances that you will keep their information private after it has crossed their jurisdictional boundary.

Reading the water for phish

Here is a list of identifying characteristics of a phishing scam. Any one of these characteristics can be a sign of a scam, but multiple characteristics are a strong indication.

  • Is the message unsolicited?
  • Does it contain misspellings or poor grammar?
  • Is the scammer trying to create a heightened sense of urgency?
  • Does the sender’s address or the hyperlink you hover over, contain an uncommon domain name?
  • Scammers often request information that a legitimate person should already have (why would a bank who is calling me need my account number?)
  • Is the offer too good (or the problem too bad) to be true
  • Scammers often state their authority over you (that they’re from a collection agency, law enforcement agency, tax agency, immigration service, especially agencies that you would have a difficult time confirming)
  • Scammers often refer to themselves only by their title or department name, and do not give a person’s name you can verify
  • If not stating their authority, they tell you how hard they are trying to save you from some disaster you didn’t even know you had
  • In this past year, there was a scam where the malicious hyperlink was the unsubscribe link! That is, by thinking you would rid yourself of the sender, you would actually fall prey to them!

If you receive a message that is suspicious because of any of these characteristics: don’t click on any of its links, don’t open any of its attachments, and don’t call any phone numbers listed in the message. If it appears to be coming from another person, you can contact that person using an address or phone number you get from a known legitimate source.

 

Gone phishin’

You are the target of phishing scams because either you possess valuable information or you are a link in the chain leading to valuable information (especially in your business persona).

There has been a huge increase in the number of Business Email Compromise (BEC) attempts. This type of scam asks you to do things you do in a normal business day, unlike earlier scams which asked you to do out-of-the-ordinary things like accept millions of dollars wired from a foreign prince.

To trigger your habits, the bait used by attackers is to play on your fears, your desire to help, and your compliance to policy; for example:

  • Someone posing as an executive or customer might demand that you fix a fake problem
  • A fake partner might ask for your assistance in selling to a fake customer
  • Someone posing as an IT administrator might demand that you reset your password by first entering your current password into a fake form

New tactics are attempting to put more realistic context around these fake demands, examples are:

  • A fake executive is telling you a fake secret about a fake acquisition, and asks for real information
  • A fake company leader references a commonly known issue, and asks you do to something to resolve it, something that sounds logical
  • An even more subtle tactic is to build confidence over multiple emails before the attacker asks for your action (aka long game or long con). This building of confidence has a long history from military spy games to Bernie Madoff’s Ponzi Scheme.

The consequences of you taking the bait is that the attacker will steal money, steal information, steal your identity, hold your information hostage for a ransom, or unleash a virus; these days though, while a virus is bad, a virus might be the least damaging consequence of you being tricked by a phishing scam.

 

Don’t rely on password validity rules and mangling

Don’t assume your password will be strong just because you follow the mandatory password validity rules of an account (that is, minimum number of characters, digits, special characters, mixed case). The password “Beyonce#1” follows most validity rules, but is a weak password. Unfortunately, many password strength meters give you a misguided sense of comfort because they only consider these basic validity rules.

Further, don’t assume that mangling certain characters will result in a strong password, like leetspeeking or other substitution ciphers; for example, substituting ‘$’ for ‘s’, ‘@’ for ‘a’, etc.

These validity rules and manglings have become antiquated because hackers already know the patterns we follow when applying them. They start with an initial dictionary of words, quotes from wikiquote.org, names of athletes, teams, bands, songs, authors, fictional characters, etc. Then, based on common patterns we use when creating our passwords, they apply validity rules and manglings to each entry of their initial dictionary to create a comprehensive final password cracking dictionary.

Therefore, before you apply validity rules and manglings, your password should already be a strong password.

For enlightenment – See these password cracking dictionaries (is one your passwords in one of them?). If you can read scripts and are comfortable browsing in the darker parts of the internet, check out John the Ripper and see some of its recommended rules which adorn initial dictionary entries with digits and special characters and mangle them.

With every new tranche of passwords that are phished or leaked, hackers add to their initial dictionaries and adapt their scripts to apply new patterns of validity rules usage and mangling.

Below are the scores from the first 8 password strength checkers returned by a Google search for password strength checker. Both sample passwords follow the same common validity rules and do so in the same way: initial uppercase letter, six lowercase letters, special character, digit. The root of the first sample is a word expected to be guessed by a dictionary crack.

Those strength checkers that score the same for both of the sample passwords are not doing any dictionary lookup and only relying on simple validity rules.

Note a wide variance in the results between checkers still exists even though this variance was identified by Mark Stockley of Sophos in 2015.

SiteScore for password Mustang#1Score for password Htqvgxb^3
passwordmeter.comscore 70% (strong)score 70% (strong)
howsecureismypassword.net4 weeks to crack4 weeks to crack
password.kaspersky.com4 minutes to crack4 months to crack
www.my1login.com/resources/password-strength-test0.57 seconds to crack100 thousands years to crack
password-checker.online-domain-tools.comscore 55% (medium), but this is not safe because “mustang” is a dictionary wordscore 55% (medium), but this is not safe because ‘Htq’ + ‘vgx’ + ‘b^3’ is not a safe word combination. The word is composed of three components: 1) The word ‘Htq’ is reverse of the dictionary word ‘qtH’. 2) ‘vgx’ is a dictionary word. 3) Words ‘bae’ and ‘b^3’ are the same after applying leet speech rules.
thycotic.com/resources/password-strength-checker/password-strength-checker-pop4 months to crack4 months to crack
www.grc.com/haystack.htm2.43 months to crack (average compute power)2.43 months to crack (average compute power)
rumkin.com/tools/password/passchk.php37.7 bits of entropy (reasonable)44.9 bits of entropy (reasonable)

Note: Microsoft used to publish an online password checker, but it seems to have disappeared: fear of liability?

Personalized passphrase

Don’t assume your password will be strong just because it is based on a sports hero or author for which you have a strong feeling. Your feeling is shared by millions of others, including hackers who already have that athlete’s or author’s name in their password cracking dictionary.

Just because your love of Beyonce is unknown to even the people closest to you, a password based on her name will not be a strong password because hackers also love her and they’ll guess that you do too.

You probably share your love of one thing with many other people, but you probably have two, three or four interests that, in combination, no one else shares. For example, as long as they cannot be guessed from public information about you, your love of Madchester bands, 3D printing, and Thomas Pynchon novels are probably not shared with anyone else in the world. Therefore, a three-word passphrase where each word comes from one of your different interests is not likely to appear in any cracking dictionary (e.g. rosesplavice), and will be a password you can remember!

…but you should be realistic: if your two interests are football and beer, blending words derived from those interests is not likely to create a unique password.

Open source governance hot potato

Who owns open source governance? Legal?

Let’s step back and consider what OSS is replacing. OSS is an alternative to developing, testing, and maintaining the software in-house.

Therefore, the use of each OSS package should be governed similarly to how one governs other external software suppliers. Unlike in-house developed software, you don’t control the open source developers, but governing open source mimics the governing of software sourced from other external suppliers.

Here is the priority of who should govern open source:

  1. Role which governs use of software developed by partner companies
  2. Role which governs use of software developed by outsourcing companies
    • Often this role makes too many optimistic assumptions about the quality of software produced by the outsourcer, so this role might not spend the necessary time evaluating the quality of the open source
  3. Role which governs use of software developed by commercial companies
    • Often this role is too concerned with financials that don’t apply to open source
  4. Each product team

So if an organization doesn’t already have one of the first three roles listed above, the responsibility for open source governance should fall to each product team. Hopefully the common leader of these product teams will recognize the overhead of distributed open source governance and centralize it, effectively creating one of the first three roles.

Certainly, the role which governs open source should consult with the Legal department as needed. However, any one of the above roles will be better able to apply all the right quality controls to ensure the security, maintainability, etc. of the open source than can the Legal department.

Simple question, not so simple answer

I have often been asked the question: “Is this a good open source license to use?”

First, this is the wrong question: the developer will not be using the license, they will be using the OSS covered by the license.

To be fair, some open source licenses are so liberal that any OSS covered by those licenses can be used in any way with no obligations or fear of legal consequences.

However, for the majority of open source licenses, the answer to the simple question depends upon complicated issues: how the OSS will be used, whether the developer can fulfill the license obligations resulting from that use, and whether the developer’s business agrees to fulfill those obligations.

In a common case, distributing a product which dynamically links with an LGPL-licensed library at least requires the developer to publish the OSS library’s copyright notice and make the OSS source code available to any customer.

In an uncommon case, distributing a product which statically links with that same LGPL-licensed library also requires the developer to make the proprietary source code of the product available to any customer. Same license, same library, but different use results in unacceptable obligations.

In another case, distributing modified CPL-licensed OSS requires the developer to make the modified source code available to any customer. If their modifications are clever enhancements that the developer’s business wants to remain trade secret, then that usage (that is, modification) results in unacceptable obligations.

Are the LGPL and CPL licenses bad? No, but they are a type of license that poses more risks, so the developer has to be careful how they use the OSS covered by these licenses.

 

Tarred with the same brush

OpenSSL consists of two major component libraries: the secure socket library and the core cryptography library (see the second sentence here).

The core cryptography library is often used by products independently from the secure socket library, but binary and source code application scanners can’t detect this distinction because both component libraries are marked with the same OpenSSL “brand”.

The many security vulnerabilities found in the secure socket library have caused all of OpenSSL to be considered as highly insecure. Therefore, when an application scanner run by an interested party (e.g. customer, partner, acquirer) detects artifacts of OpenSSL in a product, the scanner flags the entire product as insecure even if that product only uses OpenSSL’s core cryptography library.

This has either forced the software owner to patch its version of OpenSSL even when the patch only fixes vulnerabilities in the secure socket library unused by them, or forced the owner to reimplement their product to use a different cryptography library… efforts that could instead be spent on addressing security issues that are applicable to their product.

It is time for OpenSSL to separate its core cryptography library from its secure socket library and re-brand the core cryptography library to draw the distinction necessary to avoid this busy work.

Crowdsourcing without the crowd

Prior to the discovery of the Heartbleed security vulnerability in OpenSSL, the only criteria used to evaluate open source software (OSS) was whether its license terms were acceptable. Even though evaluators have since added the security of the OSS as a second criterion, that is still not sufficient.

Evaluating OSS must use all these other criteria used for proprietary software: maintainability, extensibility, usability, reliability, scalability/performance, portability, compatibility, and reusability (aka Architecturally Significant Requirements, Non-Functional Requirements, software -ities)…

…then must consider whether that OSS itself violates any copyrights or infringes any patents, and also whether all OSS it uses meets all of these criteria.

Like with proprietary software, you are not likely to find OSS that perfectly meets all these criteria, but you need to know these same criteria are relevant and know how well the OSS meets each criterion.

For example, it is tempting to assume that each OSS project is developed, tested, and maintained by its own crowd of specialized engineers. However, many OSS projects have been abandoned, which puts the burden of maintaining and extending it on each proprietary product that uses it: crowdsourcing without the crowd.

Retrieved April 27, 2017, from  https://www.openhub.net/explore/projects