This is the deck I used in my Codemash presentation, Application Risk and Reward: Protect the value you create, on 1/7/2016. The focus is on the importance of distinguishing between application risk management versus application security - focusing on both traditional risks (like IP theft) and emerging risks (side-effects of embedding analytics inside an app for the first time).

1. Sebastian Holst
Chief Strategy Officer

2. What risks should I be worried about?
How can I defend myself against these specific risks?
How do I work smart without being paranoid or naive?
How do I integrate all of this into my broader ALM and DevOps practices?

3. Application Risk Management
Application hardening (managing existing risks)
Application analytics (managing novel risks)
Incorporating risk management into ALM and DevOps
What patterns or practices can improve your chances for success?
Effective Application Risk Management Programs
Roles and workflows: Who’s best equipped to decide how much is
enough – too much – or not enough?
Resources & next steps

7. When the weight of the likelihood and impact of
an “incident” occurring is deemed to be
intolerably high, then the resulting risk must
either be avoided entirely (stop developing in
managed code or stop distributing your code –
use Azure for example – in this example) or, when
avoidance is not an option, the risk must be
reduced to a tolerable level through the use of a
“control.”
To be effective, a control must reduce the
combined weight of likelihood and impact of an
incident occurrence to a “tolerable” level.
Controls do not eliminate risks – controls make risks tolerable.

8. To be effective, the control must combine technology to obfuscate and/or monitor applications,
processes that detail how to consistently use the technology, and policies that dictate when to invoke
these processes – thus ensuring consistent and effective risk mitigation.
Controls to mitigate risks stemming from
the use of managed code include
obfuscation to lower the likelihood of an
incident occurrence (a preventative
control) and
tamper detection and defense as well as
application monitoring and analytics to
reduce the impact should an incident
occur (through faster detection and real-
time remediation).

9. Caution! As with any control, app hardening can
introduce its own set of “intolerable” risks.
These risks can originate from any one its three
“dimensions” of technology, process, and/or policy.
To be effective, application hardening and
analytics controls must:
• Reduce underlying risk to tolerable levels
WHILE ENSURING THAT THERE IS NO
• Negative impact on technology, process,
and/or policy in other risk categories.

10. Breadth • .NET (Azure, WinRT..), Java (Android, J2ME…)
Framework aware • XAML, BAML, Android…
Cross assembly • Distributed development & architecture
Debugging • Round trip, “incident response”…
Patch generation • Incremental obfuscation
IDE Integration • Visual Studio, MSBuild, command line, Eclipse, Ant…
Manufacturing
• Continuous integration, build farm, hosted, distributed, …
• Injection of tamper, exception, and usage instrumentation
Quality
• Adhere to runtime standards
• Comply with highest quality, security, localization and
accessibility standards
Support • Dedicated and specialized staff

11. Effective Risk Management

12. Action
&
Insight
Incidents
Service Levels
Usage & Outcomes
Behavior & Preferences
Reward
Preserve
App
Integrity
Integrate
into SDLC,
ALM &
DevOps
Performance
Privacy & Security
Instrumentation
Deployment & DevOps
Analytics & KPIs
Quality
High Value
Low Impact Low Friction
Day-to-day operations
Future strategies
Preserve service levels Minimize complexity

14. Effective Application Risk Management programs are
required in order to
Minimize application owner liability
Maximize 3rd party culpability

15. Patent: strong protection – almost impossible to secure software patents
Copyright: automatic – basis of most software licenses (and thus avoiding
USA’s “first sale” doctrine)
Limited to copying code/executables – not algorithms (and other
categories of “invention”)
Does not apply to independent development (white room)
Trade Secret: covers confidential information (logic) that provides a
company with a competitive edge (protection of last resort – and now
increasingly common)
Must be SECRET (the secret must be proven to have been
attained through “improper means”)

16. H.R.3326 - Defend Trade Secrets Act of 2015 and
S.1890 - Defend Trade Secrets Act of 2015
Trade Secret Theft: “the acquisition of a trade secret of another by a person
who used improper means to acquire knowledge of the trade secret.”
Improper Means:
(A) including theft, bribery… or espionage through electronic or other
means; and
(B) does not include reverse engineering or independent derivation…. “

17. What constitutes a material risk?
A: Legal, financial, and executive stakeholders
What are adequate controls?
A: Development and operational leadership
How can this be managed?
A: This might be an issue!
Technical requirements are increasingly showing up in legislation – not
technical guidance! (IP attorneys need to tell development that some reasonable effort
to prevent reverse engineering is required to preserve “trade secret” protection under the
law).

18. www.oceg.org/resources
• GRC = Governance, Risk, and Compliance

19. Effective Risk Management
• No policy IS A POLICY

20. Effective Risk Management