Mother Nature has had millennia to build up its defences to the many potential hazards and attacks it may face. So, given its wisdom and expertise on this subject, what can we as software developers learn from it and bring back to the evolution of our own application’s security? In this session we’ll explore where software and biology overlap when it comes to security and lessons we can learn from nature to improve our own application security.

1. MOTHER
NATURE
JAVA
The Security Face-Off

2. Why us?
Grace Jansen
Developer Advocate @IBM
@gracejansen27
Steve Poole
Developer Advocate @Sonatype
@spoole167

3. This talk is intended to
help you think more deeply
about security
Using examples from biology
no humans were hurt in the making of this presentation

4. Evolution has had billions of years to develop amazing
defenses - what can we learn?

5. Threats and Challenges - a quick
intro into the bad actors and pesky
microbes
Prevention is better than cure -
how to not get ill in the first place
Detection - knowing you’re infected
is the first step to getting healthy
Mitigation - What should you do to
limit the damage
Outline

6. Bad actors are trying to get into your
systems using the most sophisticated
methods

7. Drive by attacks still happen

8. Ransomware attacks still happen
That will be
6 Trillion $

9. Now it’s about supply chains and cyber war
The aim is to infiltrate infrastructure and essential
services…

10. To manipulate, terminate or disrupt
We’re all part of a supply chain.

11. Whatever their motivations - bad actors intend to:
go through your system to another (and repeat)
steal your data change your data crash your systems use your compute
power

12. How does that compare to real life - what do
biological bad actors want from us?

13. Biological bad actors
Viruses Bacteria
Fungus
- Use as a host
- To replicate and grow
- To infect others
- Parasitic for own benefit
Parasitic Worms Protozoa

15. Whether human or otherwise the bad actors have much in common.
Go through your system to another (and repeat)
Steal your data Change your data Crash your systems Use your compute power
Steal your resources
Go through you to access others (and repeat)
Take control of your
systems
Steal your energy reserves
Edit your DNA
vs vs vs vs
vs

16. ROUND 1: PREVENTION

17. Biology: Prevention
Skin
Minimal orifices
Extra defences at openings
Developed enhanced senses
Cell identification - flags
Scabs for wounds
Homeostasis
Behavioural changes
https://microbenotes.com/anatomical-barriers-of-immune-system-skin-and-mucus/

18. Software Prevention
API Gateways
reduce chance of
inadvertent extra
entry points.
Security checks and Input validation
prevents crude intrusion and manipulation
attacks.
Dependency
management tools -
keeping current is like
being vaccinated.
Nowadays there are nasty
vulnerabilities out there
Automated, high speed
CI/CD keeps the vulnerability
window a small as possible

19. It’s a DRAW

20. Summary
Biology vs Software? A draw if you take software
security seriously
Skin
Minimal orifices
Extra defences at openings
Developed enhanced
senses
Cell identification - flags
Behavioural changes
Scabs for wounds
Homeostasis
Developers may not be the first line of
defence but they are key to prevention
Basic security hygiene must be something
you just do like washing hands.
All elements of software lifecycle requires
attention.

21. ROUND 2: DETECTION

22. Biology: Detection - billions of years of tuning
Foreign body detection:
White blood cells, Antibodies, etc
Rapid Learning
Extra protection -> vaccines
Cell self-signalling (self-destruction)
Other detection:
Pain and deferred pain
Are painkillers good?

23. Software detection
Without specific tools in place only ‘gross’ events are visible
System
crashes
Complaints
about
performance
Ransomware Data on the
dark web

24. Other tools help
Specific monitoring software can help
spot attacks
AI powered tools are learning to spot
more sophisticated attack patterns
Unexpected resource usage can be
flagged.
Mostly it’s still indirect pain.
We don’t write applications to have pain
sensors

25. Round 2 Winner: Biology

26. Detection summary
Biology wins hands down.
Detection is needed to take action, guide autonomic
processes. Keep organisms alive and healthy
Simple next steps
1 - investigate the monitoring solutions available
2 - Instrument applications so that unexpected, unlikely
behavior is recorded.
A dull ache is better than nothing

27. ROUND 3: MITIGATION

28. Biology: Mitigation
Vaccines
Adaptive immune system (learning)
Make body less habitable
Getting rid of foreign cells
Coat DNA with molecules that suppress viral
genes
Limit access through the body
Patrol access routes

29. Mitigation - You do follow secure design principles?
•Minimize attack surface area
•Establish secure defaults
•Principle of Least privilege
•Principle of Defense in depth
•Fail securely
•Don’t trust services
•Separation of duties
•Avoid security by obscurity
•Keep security simple
•Fix security issues correctly
www.owasp.org
“Security by Design Principles”

30. Code
defensively.
Code quality
matters.

31. Reduce your data output and organize by
usecase
/api/v1/Users/1 /api/v1/UserDelivery/1

32. Reduce raw data being returned
/api/v1/Calendar/1?from=01122019
/api/v1/Calendar/1

33. Authorisation should match use cases - not super powers
no
powers
all
powers
/api/v1/Users
/api/v1/UserDelivery
/api/v1/Calendar
/api/v1/UserDelivery
/api/v1/Users /api/v1/Calendar
Delivery powers
Support powers Schedule powers

34. Mitigation - report unexpected behavior
Microservices may often be “stateless’ but the data is
not.
Think about how the client is expected to change their
state and log deviations.
Think wide - not all attacks come from one IP address.
Can you spot a botnet trying to authenticate with the
same userid from 1M computers?
(Tip) Be careful about the amount of extra info in a log – remember the bad guys may
gain access to them too

35. Mitigation - handle errors intelligently
try {
…
} catch(Exception e) {
// io error
expected so
ignore
}
try {
…
} catch(FileNotFoundException e1) {
log.debug(“file requested does not exist);
} catch(IOException e2) {
log.error(“unexpected …”);
}

36. Mitigation - test your dependencies
Keep checking the features you rely on to do the job.
90% of modern applications are open source
Open Source projects that have poor security
hygiene are primary targets for hackers.
(Tip: select dependencies for their good practises as
well as their feature sets)
https://twitter.com/JiliJeanlouis/status/1504737634379345924

37. How long before exploitation?

38. How much notice do you get before you get attacked?

39. How much notice do you get before you get attacked?
Is closed!

40. Round 3 Winner: Biology

41. Mitigation Summary
For software the consequences for failure are
getting higher
Our mitigation strategies need to keep pace.
Biology has strong, adaptive mitigation strategies.
Critical for changing environment - attacks are
inevitable and ever-changing
Serious consequences if this fails. No reboots.

42. And the winner is….
MOTHER NATURE

43. Takeways
Living organisms have evolved to be robust and adaptable to deal with external
threats.
Java applications can do the same.
Design for defence in depth: validate inputs, highlight unexpected behavior, keep
dependencies up to date. Take a Zero trust approach.
Take time to understand the security measures around your application and work
with them.
An application is just one cell in the system - make it an effective one

44. Useful Links
● https://openliberty.io/guides/#security
● https://www.ibm.com/docs/en/was-liberty/base?topic=securing-liberty-its-
applications
● https://dev.sonatype.com/
● https://www.owasp.org/index.php/Security_by_Design_Principles#Security_prin
ciples

45. Thank you!
Grace Jansen
Developer Advocate @IBM
@gracejansen27 Steve Poole
Developer Advocate @Sonatype
@spoole167