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
Advertisements

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/

 


‘Best Practices’ IT Should Avoid

June 20, 2017

12 ‘Best Practices’ IT Should Avoid At All Costs.

A colleague mentioned this title and I could not resist scanning the list.

They offer support to some of the funnier Dilbert cartoons, AND they should spark some reflection (maybe more) for some of us working in Global Financial Services.

1. Tell everyone they’re your customer
2. Establish SLAs and treat them like contracts
3. Tell dumb-user stories
4. Institute charge-backs
5. Insist on ROI
6. Charter IT projects
7. Assign project sponsors
8. Establish a cloud computing strategy
9. Go Agile. Go offshore. Do both at the same time
10. Interrupt interruptions with interruptions
11. Juggle lots of projects
12. Say no or yes no matter the request

If any of these ring local (or ring true), then I strongly recommend Bob Lewis’ review of these ‘best practices.’

If any of them make you wince, you might want to read an excellent response to Mr. Lewis by Dieder Pironet.

In any case, this seems like an important set of issues. Both these authors do a good job reminding us that we should avoid simply repeating any them without careful analysis & consideration.

REFERENCES:
12 ‘Best Practices’ IT Should Avoid At All Costs.
http://www.cio.com/article/3200445/it-strategy/12-best-practices-it-should-avoid-at-all-costs.html
By Bob Lewis, 06-13-2017

12 ‘best practices’ IT should avoid at all costs – My stance.
https://www.linkedin.com/pulse/12-best-practices-should-avoid-all-costs-my-stance-didier-pironet
By Didier Pironet, 06-19-2017


4 Agile Security Principles

August 30, 2016

Yesterday Citigal proposed a set of principles to complement the Agile Manifesto.  Authors of the Agile Manifesto emphasized:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Cigital offers four principles to help address inefficiencies that too often slow application security. They intent that these four principles will “guide and inspire us to build secure software in an agile way.”

  1. Rely on developers and testers more than security specialists.
  2. Secure while we work more than after we’re done.
  3. Implement features securely more than adding on security features.
  4. Mitigate risks more than fix bugs.

I assume that Citigal built their list in the Agile Manifesto model, as an expression of their valuing the items on the right — just not as much as they value the items on the left.  Not only do these principles align with and extend the original Agile Manifesto, it seems like they may also help information and software security organizations scale their efforts.  None of us has all the resources we need.  Sensitive use of the “Cigital four” listed above may help us build capacity…

These seem like an excellent resource for those leading secure software efforts as well as for architects, designers, product owners — anyone attempting to influence software quality while managing software induced risks to appropriate levels.

RESOURCES

Cigital: https://www.cigital.com/

The Agile Manifesto: http://agilemanifesto.org/

Cigital’s 4 Principals: https://www.cigital.com/resources/ebooks-and-whitepapers/agile-security-manifesto-principles/

There is no single “Agile” way: https://en.wikipedia.org/wiki/Agile_software_development#Agile_methods

 


Complex Problems Remain

October 4, 2015

All of us involved in global financial services continue to be confronted with an expanding universe of “cloud” and “mobile” and “agile” options. Too many marketers for too many of these vendors seem to exercise increasingly predatory behaviors. A key result seems to be an escalation of risk management complexity…

In that context, I have been working on some complex issues…

Hofstadter’s Law (1979) still applies.

Hofstadter’s Law states that:

"It always takes longer than 
you expect, even when you 
take into account 
Hofstadter's Law."

REFERENCES:
Hofstadter’s Law: https://en.wikipedia.org/wiki/Hofstadter%27s_law


%d bloggers like this: