Category Archives: Security

Product Composition Risk Management

September 25, 2017Data Privacy, Open Source Software (OSS), Securityadmin

When I first heard the term Software Composition Analysis (SCA), I was excited to hear of a new vision for what was thought of as only an open source discovery tool. I knew the vendors in this new SCA space were thinking more deeply about the problems faced by product owners than just generating a bill of materials which detailed the open source code used by and distributed with their proprietary code.

However, after thinking about the broad spectrum of what SCA vendor are actually doing, I came to realize that the only word in that market categorization which is fully applicable is: composition. Both the words software and analysis are far too narrow for the work being done by SCA vendors.

Software, Firmware, and Webware

Even while they have been benefitting by this market category, SCA vendors have been processing not only their customers’ desktop and server software, but also their mobile application software, device firmware, and webware written with open web APIs. Just being positioned as servicing “software” limits the perception of the wide variety of intellectual property delivery and deployment models SCA vendors process daily.

Risk Detection, Assessment, and Mitigation

Merriam-Webster defines analysis to be a “separation of a whole into its component parts”. Not only is this redundant with the word composition, but SCA vendors have gone beyond simply identifying open source components.

SCA users have consistently received more than a bill of open source materials. They have achieved well-defined business outcomes that have resulted in minimized risk around the security, data privacy, operations, license compliance, and terms of use compliance.

Product Composition Risk Management

Therefore, to represent the actual scope of benefits provided by SCA vendors, the category “Product Composition Risk Management” is more appropriate.

A modern digital product is composed of one’s own proprietary code, code from commercial and non-commercials providers, and web service providers. The word product is not limited to software, firmware, mobile, or web development; it encompasses all modes of digital product composition which use all types of intellectual property.

There is risk in composing one’s product only from one’s own proprietary code, which is why that code is measured against multiple non-functional requirements. However, composing one’s product from intellectual property owned by others creates an inherent risk that is much greater. You don’t know the care with which that IP was created and don’t know the resources available to maintain it.

SCA vendors not only identify open source risk, they assess the risk, and provide mitigation alternatives for their customers.

So, while the SCA market categorization served its purpose for a few years, it is time to acknowledge the greater benefits that SCA vendors bring to a customer’s entire supply chain.

Data Privacy Requires Data Security, Just Ask Equifax

September 20, 2017Data Privacy, Open Source Software (OSS), Securityadmin

The following post was originally published here by Black Duck Software…

The EU’s General Data Protection Regulation (GDPR) will be enforced starting May 25, 2018. One of its goals is to better align data privacy with data security, as depicted in this simple Venn diagram:

That is, you can have data security without data privacy, but you can’t have data privacy without data security.

Equifax painfully has come to this same conclusion, and well before the May 25, 2018 date.

A Little History on Data Privacy Principles

Many years ago, Equifax could have successfully argued that they have complied with data privacy requirements because they have not sold consumers data without those consumers’ permission. That was how low the bar was set when data privacy first became an issue.

Even as long ago as 1995, one of the data privacy principles in Directive 95/46/EC required appropriate security controls when handling private data. However, data privacy had focused only on issues of consumer consent and intentional disclosure of private data; that is, until Equifax clarified for uslast week that that is not enough.

GDPR: New Requirements for Security Controls

Just like with Directive 95/46/EC, one of the data privacy principles of the GPDR requires similar security controls, but the important requirement that GDPR adds is that companies must provide evidence of those security controls.

Certainly, GDPR regulators will want to see evidence of security controls, but even companies that are not directly targets of regulators will be required to produce such evidence to their customers if any company downstream in their supply chain perceives themselves to be a target of regulators. Evidence of security controls will be a condition of doing business.

The Equifax breach makes clear in a visceral way what the GDPR will make clear through regulations: the consequences to the private individual are just as damaging, if not more, when their private data is breached compared to when it is sold to an unauthorized party, ask the 140 million individuals in Equifax’s database.

David Znidarsic is the founder and president of Stairstep Consulting, where he provides intellectual property consultation services ranging from IP forensics, M&A diligence, information security management, open source usage management, and license management. Learn more about David and Stairstep Consulting at www.stairstepconsulting.com.

Compliant? Sure, But With What?

September 18, 2017Data Privacy, Open Source Software (OSS), Securityadmin

The following post was originally published here by Black Duck Software…

The term compliance is used more and more in business. Some job titles even include the term: VP of Compliance, Compliance Officer, Compliance Manager. Usually these roles have focused on the legal and operational requirements imposed by external groups like licensors and regulatory agencies.

While abiding by such external requirements is the cost of you doing business, you give up control of your business or product development by only following the requirements of others and not establishing your own policies and complying with them.

Limited Scope

Let’s look at how the term “compliance” has been used to limit the scope of open source governance…

Open source compliance has been narrowly interpreted to mean that one must abide by the open source author’s license terms. Indeed, that will always be a requirement, but consider that an open source author’s work is replacing the work of one of your own software engineers.

If the only hurdle to cross before using open source is to be compliant with the author’s license terms, that is like saying you fully trust all the code developed by one of your software engineers if and only if your management meets its legal requirements during the hiring and employment of that engineer!

A Question of Trust?

While that seems preposterous, in practice, you probably impose many more requirements on the work product of your own engineers than on the work product of open source authors. Is it your intention to trust open source authors more than your own employees? The assumptions you might be making are:

(a) every open source project is staffed by many more development, testing, and maintenance engineers than your company can deploy to solve the same problem, and

(b) those engineers know and have fixed all security vulnerabilities.

However, www.openhub.com shows that might be true for some open source projects, but not all. Therefore, unless your product teams perform the appropriate due diligence, they won’t know whether their assumptions are valid.

Open source management best practices require organizations to know the open source in their code in order to reduce risks, tighten policies, and monitor and audit for compliance and policy violations. Automating identification of all open source in use allows development and license teams to quickly gain visibility into any known open source security vulnerabilities as well as compliance issues, define and enforce open source use and risk policies, and continuously monitor for newly disclosed vulnerabilities.

Best Technology Stack Transcends Language

September 18, 2017Data Privacy, Open Source Software (OSS), Securityadmin

In Entrepreneur.com, Rahul Varshneya observes that a technology stack is often chosen by your same software or firmware developer who will be responsible for writing code in that stack’s programming language.

Who would be brave or foolish enough to recommend themselves out of a job by choosing a stack which requires expertise in a language they do not understand? Mr. Varshneya warns you to use an evaluator unbiased towards programming language.

This is because the programming language should only be one of the criteria when choosing a technology stack. However, even if an unbiased evaluator chooses a stack that meets the current and future technical needs of your company and uses the correct programming language, they can still make a wrong choice if the technology stack supplier is not right for your company.

Often evaluators choose a technology stack containing non-commercial software components that have been developed by open source authors. The additional challenge is to choose these open source “suppliers” based on your non-functional requirements.

Does your evaluator consider the security vulnerabilities that have been disclosed for each component of the stack they choose? Do they know if anyone is working on that open source component? Even if enough people are working on the open source component, how active are they? Are they making fixes, making scalability improvements, and plugging security and data privacy holes that you would expect from your own developers, or are they only adding fun-to-develop features?

Make sure you and your evaluator choose your open source technology stack suppliers based on all the same criteria you would apply if you were to hire an employee or outsourcer to develop those components for you.

We are all now in a Regulated Industry

September 15, 2017Data Privacy, Securityadmin

For many years, a small minority of companies were considered to be in a regulated industry: medical, financial, automotive, etc. Those of us not in one of those industries looked at those companies from afar with envy and pity: how are they able to produce what they produce under the weight of those regulations?

Starting May 25, 2018, we will all be in a regulated industry. Those companies who do business in the EU and UK (and thus process data identifying their citizens) will be required to comply with the General Data Protection Regulation.

The data privacy principles espoused by the GDPR are not much different than those in the Directive 95/46/EC from 1995. However, the EU has concluded that nicely asking companies for 22 years to abide by those directives has not achieved the data privacy they require for their citizens. Therefore, creating the GDPR has given teeth to regulators in the EU and UK to enforce their data privacy principles and thus brings us all into a regulated industry.

Web APIs are the New Open Source Software

September 15, 2017Data Privacy, Open Source Software (OSS), Securityadmin

If you are relaxing because you have your open source usage under control, beware. There is another increasingly common type of ungoverned third-party code that your engineers are using in your products: Web APIs.

There are many Web APIs published that, like open source software, are free of cost, readily available, provide great value, but are not free of obligations or risks. For example, https://www.programmableweb.com/api/keystroke-resolver is a Web API for mapping keystrokes from one type of keyboard to another. Perhaps useful, but what is this open source service doing with those keystrokes? Retaining them (if so, in what country)? Selling them? Marketing to your customers based on them?

Sometimes Web APIs are available to you as part of your license for a commercial software product or service. For example, you can build your own web applications using DocuSign’s published Web APIs. Use of those APIs is covered by your DocuSign license and access to them is only available to holders of an API key issued by DocuSign to paid licensees. However, even these commercial Web APIs have pitfalls for the products and services that use them.

Mistaken Assumptions About Web APIs	Non-Commercial Web APIs	Commercial Web APIs
API terms of use will remain same	Maybe Not	Probably
API implementation will remain same	No	No
API interface will remain same	Maybe Not	Probably
API will process data locally	No	No
API will be hosted in same legal jurisdiction	Maybe Not	Maybe Not
API will be available 100% of time	No	No
API has an SLA	No	Maybe Not

The Web API author’s ability to instantaneously change it is good if they fix bugs and security vulnerabilities. But it is bad if they just as instantaneously introduce new bugs and vulnerabilities, and bad if they change the functionality or interface to break your application. You have no control over whether or not you use those daily changes because you’re always using their current implementation.

Even if the Web API uses strong encryption for data in transit between your application and their server, the fact that some of this data might be personally identifiable information means not only will it be sent over a public network, but it may even be sent to another country.

Here is an example of a Web API. The current weather at a particular latitude and longitude can be found using the following URL (visit it yourself to see the results):

https://api.weatherbit.io/v2.0/current?lat=48.8583701&lon=2.2922873&key=876daf42ac7f4488956caf9011a83212

If I were a French citizen and visiting a web page that uses the weatherbit.io Web API to find out the weather at my current location, my latitude and longitude would be sent to their server in New Jersey, USA. Certainly, a data privacy concern.

To take it a step further, what Web APIs hosted by yet other parties might weatherbit.io be calling to map the latitude and longitude to my time zone? to my city? to my state? to my country?

This is another example of the newest technology being adopted by organizations before management knows about it or can govern it. This is what happened with Shadow IT. Then Shadow Engineering emerged when software developers started using open source without permission from their management or procurement departments. Now, shadow web development via Web APIs is an increasingly common way for programmers to efficiently build web applications. Today, building web applications is a composition of proprietary code, outsourced code, open source code, and open source online services accessed via Web APIs. You must understand and manage the provenance of each of these components.

Assume Every Application is an On-Premises Application

August 31, 2017Data Privacy, Securityadmin

We feel the need to label applications as either on-premises or cloud.

We try to assure ourselves that an application categorized as on-premises will not send or receive data over a public network, and an application categorized as cloud will not install client resources.

However, the reality is that most applications categorized as cloud require resources to be installed on the client, and sometimes install those resources silently.

This is usually because browsers and HTML aren’t powerful enough to drive the complexity required by those applications.

Therefore, applications categorized as cloud sometimes require native browser plugins, agents, or beacons. Sometimes they require native applications that supplement the browser client, like update utilities, upload utilities, etc. Sometimes the only client is a native application, like is the case with mobile apps.

Installing any of these requires explicit action on the part of IT or user, but are often overlooked as requirements because the application is categorized as “cloud”.

Cookies, web storage, and JavaScript are examples of client side resources installed without explicit IT or user action. Web storage is becoming more prevalent and harder to manage. It started with local shared objects (aka Flash cookies) and it continues to expand via standards like IndexedDB and proprietary client-side storage methods used by Internet service providers.

So if prevention or knowledge of an application’s required client-side installations is important to you, you need to do a technical analysis of what is and what is not installed; don’t rely on marketing materials and naïve categorizations. In the absence of such an analysis, assume every application you use requires some type of client-side installation.

Assume Every Application is a Cloud Application

August 31, 2017Data Privacy, Securityadmin

We feel the need to label applications as either on-premises or cloud.

However, the reality is that most applications categorized as on-premises send data to and receive data from the Internet.

This is usually because most applications rely on highly dynamic content that must be installed and then frequently updated on the client device or computer.

Certainly most mobile applications are just thick native clients that access one or more on-line services. Just look at the apps on your phone and tablet and guess which features, if any, of each of those apps will work if you don’t have a data connection.

Desktop and server applications also often need cloud services to function: zip code to city lookups pass your location to an Internet service, desktop publishing templates, clip art, and help system content are now all accessed remotely, and some applications even “outsource” complex computations to cloud services, sending your data outside your organization.

So if prevention or knowledge of an application’s online access is important to you, you need to do a technical analysis of what is and what is not accessed; don’t rely on marketing materials and naïve categorizations. In the absence of such an analysis, assume every application you use is sending data to and receiving data from the Internet.

Shadow Engineering

August 12, 2017Open Source Software (OSS), Securityadmin

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)

June 24, 2017Data Privacy, Securityadmin

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?

June 6, 2017Open Source Software (OSS), Securityadmin

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

May 10, 2017SecurityVPNadmin

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 enabled	VPN enabled	VPN not enabled	VPN not enabled
	HTTPS page	HTTP page	HTTPS page	HTTP page
site	Hidden	Hidden	Visible	Visible
form data	Hidden	Hidden	Hidden	Visible
response	Hidden	Hidden	Hidden	Visible

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:

My search for an “embarassing product” on ebay is visible: http://www.ebay.com/sch/i.html?_odkw=product&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Xembarassing+product.TRS1&_nkw=embarassing+product&_sacat=0
My search for information about my “embarrassing symptom” on webmd is visible: http://www.webmd.com/search/search_results/default.aspx?query=embarassing%20symptom

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

May 10, 2017Securityconfidential, proprietaryadmin

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.

Reading the water for phish

May 10, 2017Securityphishingadmin

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’

May 10, 2017Securityphishingadmin

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

May 4, 2017Securitypassphrases, passwordsadmin

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.

Site	Score for password Mustang#1	Score for password Htqvgxb^3
passwordmeter.com	score 70% (strong)	score 70% (strong)
howsecureismypassword.net	4 weeks to crack	4 weeks to crack
password.kaspersky.com	4 minutes to crack	4 months to crack
www.my1login.com/resources/password-strength-test	0.57 seconds to crack	100 thousands years to crack
password-checker.online-domain-tools.com	score 55% (medium), but this is not safe because “mustang” is a dictionary word	score 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-pop	4 months to crack	4 months to crack
www.grc.com/haystack.htm	2.43 months to crack (average compute power)	2.43 months to crack (average compute power)
rumkin.com/tools/password/passchk.php	37.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

May 4, 2017Securitypassphrases, passwordsadmin

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.

Tarred with the same brush

May 3, 2017Open Source Software (OSS), Securityadmin

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.