J Wolfgang Goerlich's thoughts on Information Security
Phone phreaking visits Apple Pay's authentication

By wolfgang. 18 May 2015 08:43

There is a new attack on Apple Pay involving an old phreak tactic. Read about it here:

Has Your Phone Number Been Stolen? Another Apple Pay Fraud Hits the Nation

The fraud works by knowing the mobile carrier and number the target uses for device identification, contacting the carrier to port the number to a phone the criminal has, then using the number to authenticate and add the criminal’s device to the victim’s Apple Pay account. Illegally porting telephone numbers has been around for some time. Criminals are re-using the old technique to subvert Apple Pay’s device authentication mechanism. 

What can consumers do to protect themselves? First, use a telephone number that is not well known for device authentication. Many people use their home landline phone number, which is often easy to discover. Second, inquire with the carrier about their policies around authorizing porting and notifying customers. Third, keep a close eye on Apple Pay for unfamiliar devices.

The ways banks can protect consumers is as old as the tactic of stealing phone numbers. It comes down to account monitoring and fraud detection. Today's behavioral analytics are equally adept at spotting misused credit cards as they are spotting misused accounts linked to Apple Pay. Banks and other financial institutions must review their anti-fraud programs to ensure they apply to emerging payment processes like Apple Pay.

All in all, this is an example of an old tactic being applied to a new payment processing system. When developing new systems, it always pays to consider how previous attacks might apply.


Risk Management | Threat modeling

Starbucks gift card fraud

By wolfgang. 15 May 2015 12:42

Starbucks is in the news as criminals abuse its online services through fraudulent gift card purchases. On the surface, the issue appears to be about consumers’ passwords and the poor practices around their use. There is more to the story, however, and I would argue two deeper concerns are the real issue. The first is in how emerging payment systems are monitored and secured. The second is in how online services are developed and maintained. 

Read the rest at: http://content.cbihome.com/blog/starbucks_giftcard_fraud


Application Security | Risk Management

Action-Oriented IT Risk Management

By wolfgang. 19 February 2015 06:15

Last week at Chicago’s Camp IT, I presented on IT risk management and concluded with focusing on the intersection of risk and action. This is a CIO Centric Approach that re-prioritizes risks based on an organization’s constraints and IT capabilities. My Chicago talk led to several good discussions, and this article quickly summarizes the method and how you can apply it to your risk management program.

The advantage, for a security owner, is in immediately seeing which concerns, once mitigated, would produce the largest reduction in the organization’s overall risk. We can then produce the annual audit phonebook with a long laundry list of recommendations.

The disadvantage, for the IT owner, is in not factoring in effort. For example, suppose one risk rated 15 takes 12 months to resolve and another takes 3 months. Yet both are listed side-by-side and prioritized equally by the security owner. The trouble stems from the risk rating exercise not bubbling up quick wins and prioritized actions.

Read the rest at http://content.cbihome.com/blog/cbi-action-oriented-it-risk-management


Risk Management

Shelfware and Constraint Analysis

By wolfgang. 20 January 2015 13:46

Risk management and, indeed, all security activities do not happen in a vacuum. We need buy-in and time from business end-users, IT professionals, and more. Yet all to often, we plan these activities without doing a joint constraint analysis. The result is work that is understaffed and simply does not get done.

A recent survey highlights this condition. "According to Osterman Research, of the $115 per user respondents spent on security-related software in 2014, $33 was either underutilized or never used at all. In other words, in an organization of 500 users, more than $16,000 in security-related software investments was either partially or completed wasted." IT staff "was too busy to implement the software properly, IT did not have enough time to do so, there were not enough people available to do so, or IT did not understand the software well enough," the report states.

Personally, I am not ready to throw the IT staff under the bus. Let's hold up a mirror. When was the last time we planned risk mitigation while taking into account IT's time and knowledge? When was the last time we included training and staffing in our business case? 

All to rarely. It is time to take constraints into account.


Risk Management

Upcoming keynote: CampIT

By wolfgang. 12 January 2015 08:56

I am keynoting the upcoming Camp IT on Enterprise Risk / Security Management

Donald E. Stephens Convention Center
5555 N River Rd
Rosemont, IL 60018

February 5, 2015

Calculating Your Acceptable Level of Risk

With so many potential risks it can be difficult to determine which an enterprise can live with, which it can't, and which it can cope with when reduced to an acceptable level of risk. Determining an acceptable level of risk needs to be undertaken when there is a significant change in a business' activities within the environment. Examples are updating policies and training or improving security controls and contingency plans, the risks need constant monitoring to ensure the right balance between risk, security and profit.

In this session attendees will learn how to build a framework to define an acceptable level of risk. 


Risk Management

Risk management circa 2018

By wolfgang. 5 December 2013 18:11

This past Tuesday, I was out at Eastern Michigan University speaking with information assurance students. The prof invited me to visit his Risk-Vulnerability Analysis class and asked that I give my Practical Risk Management talk.

Practical Risk Management was a talk I had given widely in 2007-2008, describing my efforts to stand up a risk management practice for a financial services firm. The case study covers aspects that I found went surprisingly well, and aspects that I found were surprisingly hard. Since five or six years had passed, I had expected to have to significantly revise the slide deck. Clearly, lots has changed, right?

Surprisingly, no.

The areas we wrestled with last decade remain challenging for clients and organizations today. I found little had changed. On the bright side, that fact simplified my revisions to the slide deck for Eastern Michigan University. On the down side, of course, that means we continue to struggle.

Why? In part, it is because of the seductive simplicity of the Risk = Asset * Vulnerability * Threat formula. Find the values, plug them in, multiply, and prioritize. Easy, right?

Easy, except asset management and valuation is tricky. Few organizations have a reliable hardware and software inventory. Fewer still have automated audits and the ability to see, immediately, when the inventory changes. This matters as such changes are often an indicator of compromise. Few organizations, too, can tie assets to business processes and provide financial valuation on impact. The question of what we have and why it matters is elusive.

And vulnerability management? Putting the dependency on an accurate asset inventory aside, vulnerability management is not quite a slam dunk either. True, software such as Qualys takes the grunt work out of the process. Automation can also shift from annual assessments to continuous vulnerability assessments. Yet the real difficulty in vulnerability management continues to be driving the remediation efforts. Thus we see many vulnerability management programs with tens of thousands of open vulnerabilities.

Threat management has made some progress. In 2008, my chief concern was a lack of threat intelligence and information on what actual attackers were using to achieve actual objectives. Today, we have better information sharing (ISACs, CERTs). We also have services like Risk I/O that map vulnerabilities to threat intel feeds. Tighter integration goes a long way towards prioritizing on realistic risks. Nevertheless, as evidenced by penetration test results, the gaps in asset and vulnerability management, combined with control weaknesses and architectural security concerns, offer the motivated threat actor a variety of ways to compromise an organization.

Five years of time, with not much progress to show for it. This has me saving a copy of my slide deck to give again in 2018.

What changes can we make to obsolete my Practical Risk Management talk? Simple. We can beef up and automate asset management. We can shift from the technical aspects of vulnerability management to the social aspects, facilitating remediation efforts with other departments. Finally, we can more tightly integrate threat intel with vulnerability management and begin doing regular red team assessments to identify architectural and control concerns. In three broad strokes, we can make a dent technical aspects of risk management and enable us to get out of the weeds.

Asset management. Vulnerability management. Threat management. Three areas, three programs, three ways to make a significant difference between now and 2018. The clock is ticking. Let’s get this done.


Risk Management

Boulder rolling in Dark Reading

By wolfgang. 17 July 2012 12:29

My BSides Cleveland talk got some attention, and was part of a Dark Reading article on risk management. Check out 4 Reasons Why IT Security Needs Risk Management, also available as a PDF on my Press page.

"Traditional IT security has what I think of as a Sisyphus complex," says J. Wolfgang Goerlich, information systems and security manager for a Midwest financial services firm. "Every day, we roll the boulders up hill. We leave with as many systems, or boulders, secure as possible at the top of the hill. Overnight, new attacks are formed and new vulnerabilities are released. The next morning, some systems are insecure again, and we start again rolling boulders back up hill."

According to Goerlich and many of his peers, if security organizations are to evolve past that daily toil and affect meaningful change on their respective businesses, they need to embed risk management principles in their decision-making framework. "Moreover, rolling the boulder isn’t the goal of security, but rather the goal is securing the ability of the organization to accomplish its mission," he says. "Risk management is an important technique that focuses security efforts on the organization’s mission and prioritizes efforts on critical systems."

But what is important to the organization? What value does any given piece of technology deliver to the organization's mission? To answer these questions, we have to step back first.

The first step in building an effective security program is aligning with executive management and tying security tasks back to business objectives. Once that is done, we can move on to building a ITGRC function (IT governance, risk, and compliance). But executive sponsorship is key, otherwise, it will be extremely difficult to get feedback and support from the business units. The importance of this support cannot be overstated. Pierluigi Stella, CTO, Network Box USA, says: "Proper risk management is done when IT is only the project manager but every single business unit contributes its own knowledge to the process; and this needs to start from the top, from the C levels."

It is all part of building a mature information security program. For my full thoughts on building such a program, you can watch my BSides Cleveland Naked Boulder Rolling talk.


Risk Management

Remediating IT vulnerabilities

By wolfgang. 17 October 2011 10:20

You might say that InfoSec risk management is effectively asset management, threat management, and vulnerability management. What do we have? Who would want to attack it? And what attack vector would they use? The prioritization of fixing or mitigating the vulnerabilities is based on business impact. That is, a measure of how such an attack would affect an employee's productivity and an organization's mission. The following article gives a good overview of the vulnerability side of the process.

Remediating IT vulnerabilities: Quick hits for risk prioritization

Use multiple information sources. As J. Wolfgang Goerlich, network operations and security manager for a mid-sized money management firm told me, he looks for reports that provide "solid information regarding what the threats are and at what frequency they’re occurring."

To keep the fix process focused and effective, know your environment and business impact, create meaningful metrics that take into account public and private ratings, and stay on plan with preset time-to-fix periods.

This article is also on my Press Mentions page.


Risk Management

I fight for the users

By wolfgang. 12 October 2011 07:31

There is no patch for stupidity. L-users. Pebcak: problem exists between chair and keyboard. ID10T error. We had everything secure, but then we had to let the users on. We have all heard the jokes.

The problem is that this mindset sets us up against the users.

Corporate security teams need less "I fight the users" and more "I fight for the users". Yes, I am quoting Tron. Here’s a clip with the iconic line:

Tron: Legacy clip on YouTube

Security teams protect the organization’s mission and profitability. That fundamentally means protecting a user’s productivity. Protecting IT systems is secondary. That is a bit of a mindset shift, I know, but bear with me.

What does it mean to fight for the users? It means viewing IT security breaches in the perspective of the impact to the business's mission. It means viewing IT security controls in the perspective of the impact on user’s productivity. Fighting for the users is central to business-centric risk management.


Risk Management | Security

Learning the wrong lesson from DigiNotar

By wolfgang. 23 September 2011 12:51

DigiNotar declared bankruptcy this week, following a high profile attack that lead to malicious certifications being issued. Some five hundred certifications were issued, for everything from Google, to Twitter, to Microsoft, to the entire *.com and *.org namespace. Major browsers quickly removed DigiNotar's root from the chain, thus protecting folks from these rouge certifications. And then DigiNotar was no more.

People are already saying this proves that IT security breaches put companies out of business.

I believe that is the wrong lesson.

Let's take four companies with high profile breaches: DigiNotar, Distribute.IT, Sony, and TJXX. DigiNotar went bankrupt. Distribute.IT? Shuttered. Sony is back to business (handling it with an update to their SLA.) TJX is unaffected.

So why did TJX survive? At first, this does not make much sense. But consider the attack as it relates to impact to the organization's mission.

TJX is in retail and has reasonably deep pockets. The attack did not so much as ruffle its ability to sell product. Save for a dip during the fall out from the attack, TJX did not suffer economic harm.

Sony is in the business of providing access to its services. Though the attack was not necessarily about availability, the attack severely affected Sony's ability to reach the customer. They have deep pockets, however, and are making their way back. The reasoning behind the service level agreement and terms and conditions agreements is to minimize the cost exposure of future breaches.

Distribute.IT was in the hosting business. Their job was to keep other companies sites online, available, and protected. The attack was an availability attack that was made worse due to mismanagement of data backups. Distribute.IT, without the cash reserves and without any means to get back to business, was dead in the water.

The attack on DigiNotar struck right at the heart of their business. The mission of a certificate authority is to safeguard certificates and ensure issuance only to legitimate entities. We are talking about reliability and authenticity attacks against a company that markets a reliable and authentic security service. Further, due to DigiNotar's limited reach (fewer than 2% of SSL hosts), there was little risk for the browser makers to remove DigiNotar's root.

The lesson here is security controls must be framed within the context of the organization's mission. Breaches can be weathered if the impact is low or in an area outside the core mission. Security breaches only put companies out of business when controls are not appropriately geared to the organization and when the financial impact is serious.


Operations Security | Risk Management | Security

    Log in