Panera Bread Didn’t Take Security Seriously

April 3, 2018

I finally just read Brian Krebs and Dylan Houlihan on the 2017-2018 Panera Bread data breach of millions of customer records via unsafe APIs and applications.  This breach involved a collection of seriously flawed and insecure software wrapped in seriously flawed management.  Everyone in our business should read this and ensure that our leaders do too.  Could this happen to your organization?

Dylan Houlihan had a couple excellent recommendations.  He wrote:

 

  • “We need to collectively examine what the incentives are that enabled this to happen. I do not believe it was a singular failure with any particular employee. It’s easy to point to certain individuals, but they do not end up in those positions unless that behavior is fundamentally compatible with the broader corporate culture and priorities.”
  • “If you are a security professional, please, I implore you, set up a basic page describing a non-threatening process for submitting security vulnerability disclosures. Make this process obviously distinct from the, “Hi I think my account is hacked” customer support process. Make sure this is immediately read by someone qualified and engaged to investigate those reports, both technically and practically speaking. You do not need to offer a bug bounty or a reward. Just offering a way to allow people to easily contact you with confidence would go a long way.”

 

REFERENCES:

“No, Panera Bread Doesn’t Take Security Seriously.” By Dylan Houlihan, 04-02-2018
https://medium.com/@djhoulihan/no-panera-bread-doesnt-take-security-seriously-bf078027f815

“Panerabread.com Leaks Millions of Customer Records.” By Brian Krebs, 04-02-2018
https://krebsonsecurity.com/2018/04/panerabread-com-leaks-millions-of-customer-records/

Advertisements

Deception Has a Place in Secure Software

April 1, 2018

Deception has been standard military practice for millennia.  Attackers and defenders employ deception for a variety of goals:

Deceive – Cause a person to believe what is not true
Degrade – Temporary reduction in effectiveness
Delay – Slow the time of arrival of forces or capabilities
Deny – Withhold information about capabilities
Destroy – Enemy capability cannot be restored
Disrupt – Interrupt or impede capabilities or systems
Divert – Force adversary to change course or direction
Exploit – Gain access to systems to collect or plant information
Neutralize – Render adversary incapable of interfering with activity
Suppress – Temporarily degrade adversary/tool below level to accomplish mission

The U.S. military uses what they call a “See, Think, Do” deception methodology.

The core idea is to manipulate the cognitive processes in the deception target’s mind that result in targeting decisions and in adversary actions that are advantageous to our operations, our tactical or strategic goals.  This methodology tends to result in looping through the following three questions:

(1) What does the target of our deceptive activities see when they observe our operations?
(2) What conclusions does that target draw from those observations?
(3) What action may the target take as a result of the conclusions based upon those observations?

Successful deception operations are those that do more than make the target “believe” or “think” that the deception is true.  Success also needs to result in action(s) or inaction that supports the our operational plan(s).

Deception tactics can target human attackers, their organizations, their code, or any set thereof.

It is standard practice across global financial services enterprise information security to implement layers of protections — never depending on only a single security device.  We are at a stage in the battle with global cybercrime that may demand we introduce deception as a new layer of defense.  When we architect, design, and implement our applications and systems, we may enhance our resistance to attack by employing tactics analogous to military deception to influence attackers and the hostile code they use.  This will not be quick or easy.

Who might you assign to this task?  Do not immediately regress to: “I wonder who is available.”  Like many security tasks, deception planning requires a relatively unique skillset.  We build and deploy our software in ways that expose a multitude of interfaces.  That practice results in complex and often numerous abuse cases.  Our worker will need to understand and analyze that matrix from a number of perspectives, and to project other’s thinking and actions into the future.  We might expect them to:

  1. Understand each component’s deception and other information operations/influence capabilities.
  2. Be intimately familiar with their organization’s missions and focus.
  3. Understand the concepts of centers of gravity, calculated risk, initiative, security, and surprise.
  4. Understand friendly and adversary intelligence systems and how they function.
  5. Possess technical understanding of intelligence sensors, the platforms on which they deploy, their reporting capabilities, and associated processing methodologies.
  6. Understand the psychological and cultural factors that might influence the adversary’s planning and decision making.
  7. Understand potential adversaries’ planning and decision-making processes (both formal and informal).
  8. Understand the assets that are available to support the deception.
It is more difficult than just that.  We live in a world of laws, regulations, contracts, and norms that will constrain our behaviors in ways that differ from what may be acceptable on other battlefields.  Our leaders and practitioners need to understand those limits and manage their activities in ways that align with our obligations.  This will require much more than technical and operational competence.  It requires a high level of maturity and a finely calibrated moral & ethical compass.  Superior deception campaigns will require careful planning, effective guard-rails, and serious management.
Darn!  Another difficult staffing challenge…
Get use to it if you want to deliver your applications to a user-base anywhere on the Internet, and/or if you want to run your business in the cloud — especially if your are a global financial services enterprise — you need to expand and enhance your threat resistance using deception.
What do you think?

REFERENCES:

“Influence Operations and the Internet: A 21st Century Issue Legal, Doctrinal, and Policy Challenges in the Cyber World.”
“JP 3-13.3, Operations Security.” 04 January 2012
http://www.dtic.mil/doctrine/concepts/concepts.htm

Recent US-CERT & FBI Alert A Good Read — Applicable to Us

March 19, 2018

The United States Computer Emergency Readiness Team (US-CERT) recently released an alert about sophisticated attacks against individuals and infrastructure that contained an excellent explanation of the series of attacker techniques that are applicable to all global Financial Services enterprises. Many of the techniques are possible and effective because of the availability of direct Internet connections. Absent direct Internet connectivity, many of the techniques detailed in the CERT alert would be ineffective.

Global Financial Services enterprises, responsible for protecting hundreds of billions, even trillions of dollars (other people’s money) are attractive cybercrime targets. We are also plagued by hucksters & hypesters who are attempting to transform our companies into what they claim will be disruptive, agile organizations using one or another technical pitch that simply translates into “anything, anywhere, anytime.”  The foundation of these pitches seems to be “Internet everywhere” or even “replace your inconvenient internal networks with the Internet” while eliminating those legacy security and constraining security practices.

We can all learn from the details in this Alert.

From the alert:

[The] alert provides information on Russian government actions targeting U.S. Government entities as well as organizations in the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors. It also contains indicators of compromise (IOCs) and technical details on the tactics, techniques, and procedures (TTPs) used by Russian government cyber actors on compromised victim networks. DHS and FBI produced this alert to educate network defenders to enhance their ability to identify and reduce exposure to malicious activity.

DHS and FBI characterize this activity as a multi-stage intrusion campaign by Russian government cyber actors who targeted small commercial facilities’ networks where they staged malware, conducted spear phishing, and gained remote access into energy sector networks. After obtaining access, the Russian government cyber actors conducted network reconnaissance, moved laterally, and collected information pertaining to Industrial Control Systems (ICS).

Take the time to review it. Replace “industrial control systems” with your most important systems as you read.

For many of us, the material may be useful in our outreach and educational communications.

The 20-some recommendations listed in the “General Best Practices Applicable to this Campaign” section also seem applicable to Financial Services.

REFERENCES
“Alert (TA18-074A) Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors.” Release date: March 15, 2018. https://www.us-cert.gov/ncas/alerts/TA18-074A

“Cyberattacks Put Russian Fingers on the Switch at Power Plants, U.S. Says.” By Nicole Perlroth and David E. Sanger,The New York Times. https://www.nytimes.com/2018/03/15/us/politics/russia-cyberattacks.html


Cloud Risk Assessment Challenge Thoughts

February 3, 2018

Technology is often at the center of efforts to sell new business models. From some perspectives, “Cloud” is more about new business models than about technology-enabled capabilities. Over the last decade or more, “cloud” marketers and hypists have constructed intricate structures of propaganda that trap the unwary in a matrix, a fog, a web of artifice and deceit.[1]  I think that a “cloud first” belief system is misused in ways that sometimes results in excessive risk-taking.  Belief systems are tricky to deal with and can cause some to dismiss or ignore inputs that might impact core tenets or dogma.

My reading and first hand experience lead me to believe that many are willing to migrate operations to other people’s computers — “the cloud” — without clearly evaluating impacts to their core mission, their risk management story-telling, and risk posture. Too many cloud vendors remain opaque to risk assessment, while leaning heavily on assertions of “compliance” and alignment with additionally hyped ancillary practices [containers, agile, encryption, etc.].

None of this rant implies that all Internet-centric service providers are without value. My core concern is with the difficulty in determining the risks associated with using one or another of them for given global Financial Services use cases.  That difficulty is only amplified when some involved exist within a reality-resisting “cloud first” belief system.

Because some “cloud” business models are exceptionally misaligned with global Financial Services enterprise needs and mandates, it is critically important to understand them. A given “cloud” vendor’s attack surface combined with a prodigious and undisciplined risk appetite can result in material misalignment with Financial Services needs. Again, this does not invalidate all “cloud” providers for all use cases, it elevates the importance of performing careful, thorough, clear-headed, evidence-informed risk assessments.  In our business, we are expected, even required, to protect trillions of dollars of other people’s money, to live up to our long and short term promises, and to comply with all relevant laws, regulations, and contracts.  And we are expected to do so in ways that are transparent enough for customers, prospects, regulators, and others to determine if we are meeting their expectations.

  • Evidence is not something to be used selectively to support beliefs.
  • Research is not hunting for justifications of existing beliefs.
  • Hunt for evidence. Use your cognitive capabilities to evaluate it.
  • Soberly analyze your beliefs.
  • Let the evidence influence your beliefs.
  • When needed, build new beliefs.[2]

Effective risk management has little room for anyone captured within a given belief system or abusing the power to create one’s own reality.

This remains a jumbled and unfinished thought that I will continue to evolve here.

What do you think?

[1] Derived from a phrase by Michelle Goldberg.
[2] Thank you Alex Wall, Johnston, IA. Author of a Letter to the Editor in the Feb 3, 2018 Des Moines Register.


Risk-Taking and Secure-Enough Software

January 24, 2018

Each of us involved in global Financial Services enterprises have risk management strategy and policy.  In action, those are supported and operationalized through a vast, dynamic, organic, many-dimensional web of risk management activities.

One facet of this activity involves the creation, acquisition, implementation, and use of risk-appropriate software. Sometimes this is abbreviated to simply “secure software.” In some forums I use the term “secure-enough software” to help highlight that there is some risk-related goal setting and goal achieving that needs to be architected, designed, and coded into software we create — or the same needs to be achieved by our vendors or partners when we acquire software.

As I have mentioned repeatedly in this blog, global financial services enterprises succeed through taking goal-aligned risks. Our attempts to live out that challenge are at best uneven.

Some software developers, architects, or some agile team member will zealously and enthusiastically take risks in their attempts to improve a given or a set of software quality characteristics. Others only reluctantly take risks.[1] In either case, the risks are only vaguely described (if at all) and the analysis of their appropriateness is opaque and un- or under-documented.

My experience is that too many personnel have little to no involvement, training and context on which to ground their risk analysis and risk acceptance decision making.  As a result of that gap, risk acceptance throughout any software development lifecycle is too often based on project momentum, emotion, short term self-promotion, fiction, or some version of risk management theater.

The magnitude of risk associated with this type of risk taking has only been enlarged by those attempting to extract value from one or another cloud thing or cloud service.

Those of us involved in secure software work need to clearly express the extent of our localized organization’s willingness to take risk in order to meet specific objectives, AND how the resulting behaviors align with published and carefully vetted enterprise strategic (risk management) objectives.

All of this leads me to the topic of risk appetite.

  • What needs to be included in a description of risk appetite that is intended for those involved in software development and acquisition?
  • Are there certain dimensions of software-centric risk management concern that need to be accounted for in that description of risk appetite?
  • Are there certain aspects of vocabulary that need to be more prescribed than others in order to efficiently train technical personnel about risk-taking in a global financial services enterprise?
  • Are there rules of thumb that seem to help when attempting to assess the appropriateness of given software-centric risks?

What do you think?

REFERENCES:

Risk Appetite and Tolerance Executive Summary.
A guidance paper from the Institute of Risk Management September 2011
https://www.theirm.org/media/464806/IRMRiskAppetiteExecSummaryweb.pdf

[1] A similar phrase is found in the abstract of “Risk Appetite in Architectural Decision-Making.” by Andrzej Zalewski. http://ieeexplore.ieee.org/document/7958473/

 


Ransomware and My Cloud

December 10, 2017

I just reviewed descriptions of sample incidents associated with ransomware outlined in the ‘Top 10″ review by TripWire.

Ransomware attacks — malware that encrypts your data followed by the attacker attempting to extort money from you for the decryption secrets — are a non-trivial threat to most of us as individuals and all financial services enterprises.

Unfortunately for some, their corporate culture tends to trust workforce users’ access to vast collections of structured and unstructured business information.  That ‘default to trust’ enlarges the potential impacts of a ransomware attack.

As global Financial Services security professionals, we need to resist the urge to share unnecessarily.

We need to quickly detect and respond to malware attacks in order to constrain their scope and impacts.  Because almost every global Financial Services enterprise represents a complex ecosystem of related and in some cases dependent operations, detection may involve many layers, technologies, and activities.  It is not just mature access/privilege management, patching, anti-virus, or security event monitoring, or threat intelligence alone.

All of us also need to ensure that we have a risk-relevant post-ransomware attack data recovery capability that is effective across all our various business operations.

So, does the cloud make me safe from ransomware attack?  No.  Simply trusting your cloud vendor (or their hype squad) on this score does not reach the level of global Financial Services due diligence.  It seems safe to assert that for any given business process, the countless hardware, software, process, and human components that make up any cloud just make it harder to resist and to recovery from ransomware attack.  And under many circumstances, the presence of cloud infrastructure — by definition, managed by some other workforce using non-Financial Services-grade endpoints — increases the probability of this family of malware attack.

 

REFERENCE:

“10 of the Most Significant Ransomware Attacks of 2017.” By David Bisson, 12-10-2017. https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/10-significant-ransomware-attacks-2017/​


Innovation and Secure Software

November 15, 2017

​I sometimes get questions about the applicability of secure software standards and guidelines to work described as innovation or innovative.  Sometimes these interactions begin with an outright rejection of “legacy” risk management in the context of an emerging new “thing.”  I believe that under most circumstances, any conflict that begins here is voluntary and avoidable.  As global financial services organizations, our risk management obligations remain in force for mature & stable development projects as well as for innovation-oriented efforts.

In any discussion of innovation, I arrive with my own set of assumptions:

  • Innovation can occur at all levels of the human, business, operations, technology stack, and often requires concurrent change at multiple layers.
  • Innovation, in any context, does not invalidate our risk management obligations.
  • One of the most common and insidious innovation anti-patterns is constantly looking for the next hot tool that’s going to solve our/your problems.*

Software-centric innovation may generate new or help highlight existing gaps in your secure software standards/guidelines.

If there are gaps in your existing secure software guidance — so that the new “thing” seems to be out of phase and disconnected from that legacy, those gaps need to be closed.

Sometimes gaps like these appear because of changes in vocabulary.  This is generally an easy issue to deal with.  If all involved can agree on the trajectory of the innovative development, then you can begin with something as simple as a memo of understanding, with updates to secure software standards/guidelines to follow at a pace determined by the priority of that work (if there is a formal, fines & penalties regulatory compliance issue involved, it is a higher priority than if were only an exercise in keeping your documentation up-to-date).

Other times an organization is introducing a new business process, a new type of business, or a new technology that does not map well to the existing concepts and/or assumptions expressed in your secure software standards/guidance.  An example of this situation occurred as we all began to invest in native mobile apps.  At that time, mobile app ecosystems did not incorporate a lot of the common security mechanisms and capabilities that had been in place for server and desktop environments for a long time.  This type of change requires a mix of simple vocabulary and content change in corporate secure software standards/guidance.  Again, if those involved can agree on some fundamental assumptions about what the new software is doing and where it is executing, along with sharing an understanding of its external behaviors (passing data, resolving names, signaling, trusts, etc.), you can take a multi-step process to get secure software guidance synchronized with your business environment.  The first step being some sort of formal memo of understanding, followed by the research, collaboration, and writing required to get your secure software standards/guidelines and your business operations back into phase.

Is it possible that your enterprise could introduce something so alien and so disruptively new that there was just no connective tissue between that investment and your existing secure software guidance?  Sure.  What if financial services enterprises decided that they needed to begin building our own proprietary hardware (from the chips all the way up the stack to network I/O) to deal with the combination of gigantic data-sets, complex analyses, and extremely short timelines (throw in some ML & AI to add sex appeal).  Our current generation of secure software standards/guidelines would not likely be well aligned with the risk management challenges presented by microchip architecture, design, implementation and the likely tightly-coupled low level software development that would be required to use them.  I would not be surprised if much of what we have currently published in our organizations would be virtually unrelatable to what would be needed to address the scenario above.  I think that the only businesslike path to dealing with that secure software challenge would be to acquire highly-specialized, experienced human resource to guide us through that kind of dis-contiguous evolution.  That would be a material challenge, but one that our business will not often face.

Given the current state of our secure software training and guidance resources, it seems like most of us in global Financial Services enterprises should expect to find that most ​innovation efforts are aligned-enough with the existing secure software standards/guidelines, or (less frequently) only somewhat out of sync because of differences in vocabulary, or misaligned underlying assumptions or concepts.  Those are expected as part of our evolving software-driven businesses and the evolution of hostile forces that our businesses are exposed to.

So, innovate!  Any of our success in the global financial services marketplace is not guaranteed.  And, dive into working through decision-making about your architecture, design, and implementation risk management obligations.  And finally, use the existing technical and human resources available to you to deal with any new risk management challenges along the way.

* Rough quote from: “Practical Monitoring: Book Review and Q&A with Mike Julian.” By Daniel Bryant, Nov 07, 2017. https://www.infoq.com/articles/practical-monitoring-mike-julian.


%d bloggers like this: