Phone phreaking visits Apple Pay’s authentication

Archive for the ‘Threat Modeling’ Category

Phone phreaking visits Apple Pay’s authentication

Posted by

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
https://www.mainstreet.com/article/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.

Exercising with Threat Models

Posted by

The video of my GrrCon talk is now online. If you want to see the talk in context of my year-long series, please see my post on Story-Driven Security.

 

Exercising with Threat Models @ GrrCon 2014

Everyone advocates for threat modeling. Few actually do it. This session aims to close that gap by demonstrating the #misec Attack Path methodology. First, we will select and analyze a security incident. Using threat modeling, we will break the incident down into the path the attacker followed through the network. Second, we will perform a table top exercise to identify the detective and preventative controls along that path. Using a controls assessment, we can determine our actual defense-in-depth for this particular attack. Finally, we will create a security exercise that tests the controls along the path. The session will conclude with a discussion of using the Attack Path for incident response exercises.

Story-Driven Security and Threat Modeling

Posted by

I continue to expand the Story-Driven Security concept that I discussed a few years back. Over the past six months, I have fleshed out its role in the security program (GrrCON), the method for creating the models (CircleCityCon), using those models to run incident response drills (GrrCON), and finally its use in driving change (BSides Chicago). Below are links to talks that cover these areas. Check it out, give it a try, and please provide me feedback.

Beautiful Models @ GrrCON 2013

We need beautiful models. Models attract and hold your attention. They excite you. They prompt action. And action, excitement, and focus is exactly what is needed to defend IT. By models, of course, we mean threat models. Intricate and beautiful, a good threat model tells a story. It indicates what we are protecting and where the attacks may come from. Done right, modelling highlights both the strengths and weaknesses of our IT. It becomes a means for strengthening and focusing our efforts. We need beautiful models to see what is and what could be. This session will explore threat modeling as part of the secure development lifecycle. A case study will be presented. The stories are real and only the names have been changed to protect the innocent. Beautiful Models answers the question: what is it that makes a threat model beautiful and actionable?

How to create an attack path threat model @ CircleCityCon

Everyone advocates for threat modeling. Few actually do it. This session aims to close that gap by demonstrating the #misec Attack Path methodology. First, we will select and analyze a security incident. Using threat modeling, we will break the incident down into the path the attacker followed through the network. Second, we will perform a table top exercise to identify the detective and preventative controls along that path. Using a controls assessment, we can determine our actual defense-in-depth for this particular attack. Third and finally, we will create a security exercise that tests the controls along the path. The session will conclude with a discussion of using the Attack Path for incident response drills.

Exercising with Threat Models @ GrrCon 2014

Now that we have a threat model, let’s cover using the model to create and execute security exercises.

Aligning Threats and Allies through Stories @ BSides Chicago 2014

Successful defense occurs when the interests of a security team’s stakeholders intersect with the attackers actions. This session provides a three-part management methodology to enable defense-in-depth through effective stakeholder and threat management. Internally, the method models the political power of our target audience, the audience coverage of our message, the timing, and the benefits used to influence our audience. Externally, the method models the attacker’s objectives, tactics, techniques, and mitigating controls. Using this story-driven security methodology, we can identify what our allies need, identify what our attackers want, and build business cases to satisfy one while thwarting the other.

(Updated: 2014-06/18 following CircleCityCon)
(Updated: 2014-10/18 following GrrCon)

Video of my GrrCon Threat Modeling Talk

Posted by

GrrCon posted video of my 2013 talk. My talk is kicking off a collaboration with #misec to create a threat modeling methodology. We held our first working session on 10/26. The next steps include talks at BSides Jackson (Mark Kikta), at next week’s #misec meeting (Steven Fox and me), and next month’s ISSA meeting (Mark and me). A formal threat modeling workshop will be held in Q1 2014. Stay tuned for more.

 

GrrCON 2013- Beautiful Models – J Wolfgang Goerlich
http://www.youtube.com/watch?v=82_lYv5CDy8

We need beautiful models. Models attract and hold your attention. They excite you. They prompt action. And action, excitement, and focus is exactly what is needed to defend IT. By models, of course, we mean threat models. Intricate and beautiful, a good threat model tells a story. It indicates what we are protecting and where the attacks may come from. Done right, modelling highlights both the strengths and weaknesses of our IT. It becomes a means for strengthening and focusing our efforts. We need beautiful models to see what is and what could be.

 

This session will explore threat modeling as part of the secure development lifecycle. A case study will be presented. The stories are real and only the names have been changed to protect the innocent. Beautiful Models answers the question: what is it that makes a threat model beautiful and actionable?

Monitoring attack paths

Posted by

SIEMs are used for establishing security controls and responding to attacks. From my SimWitty days to my new role managing VioPoint’s SOC, we draw a distinction between these two. For controls-based activities, we think in terms of use cases. A SIEM use case defines a particular way the SIEM gathers and reports on data. For threat-based activities, an abuse case that defines an attacker’s activity and how the organization would detect the activity. The use case drives value and the abuse case protects against value loss.

Abuse Cases Map Possible Paths

An abuse case begins by describing the attacker and their objectives. Who are they? What are they after? What tactics and techniques are these attackers likely to use? From there, the abuse case defines the path the attacker would take to achieve their objectives. For example, a typical abuse may include:

(1) External reconnaissance
(2) Initial breach
(3) Escalate privileges
(4) Persistence
(5) Internal reconnaissance
(6) Lateral breach
(7) Maintain presence
(8) Achieve objective

The modus operandi will thus be modeled for a particular threat.

The Final Step In Monitoring

The final step in using SIEM to respond to attacks is to overlay the abuse case with the technical controls. How would we detect and prevent a particular tactic used in persistence, for example? What about the lateral breach phase in an attack path? Thinking through these controls allows us to give ourselves credit for where we are doing well, and allows us to identify opportunities for enhancing the controls.

To get the most out of a SIEM, from a threat perspective, we create a set of high-level threat models and setup monitoring along the identified attack paths. A well-defined abuse case does just that.