AppSensor is an OWASP project that enables you to build self-defending applications with attacker detection and automated response capabilities. There are many security protections available to applications today. AppSensor builds on these by providing a mechanism that enables architects and developers to build into their applications a way to detect events and attacks and then automatically respond to them.
7. not too long ago dev
• mostly web apps
[RoR, PHP, .NET, Java)
• ajax (jquery) use
growing
• mobile just getting
started
• deployment to VMs
• hadoop picking up
• BI tools
• AWS starting
• cloud hype cycle
(NIST defines)
12. dev vs. security
• dev is exploiting fundamental
architectural and deployment changes to
add business value
• security is iterating on existing solutions -
and - trying to close gaps (known
problems)
14. traditional “security”
• confidentiality and
integrity important
• availability often
ignored by security
(informs the whole
industry- eg. tooling)
• if availability important,
runtime important
22. catching defects
• what do dev/qa do for functionality?
• test [unit, integration, system, manual,
tools]
• what do attackers do for security?
• test [automated tools, manual]
23.
24.
25. observations
• attackers do bad things
• bad things often easily recognizable (to you …
in your business … if you’re looking)
• attacker success often* requires > 1 attempt
* If not, you lose
32. security modern dev
• a single mature,
static language
• monolith
• http (really html)
endpoints
• polyglot static and
dynamic languages
• microservices / soa
• json, thrift, protobuf,
grpc, etc. endpoints
• WebAssembly ???
36. in summary (so far) …
• “traditional” security, dev, ops doesn’t know what’s going on
in the app at runtime (holistically)
• security defects exist
• attackers don’t magically know what’s vulnerable
• existing (security) “monitoring” is usually terrible
• there will never be enough “security” people
• “traditional” security tooling doesn’t fit modern dev
… actual defense is _really_ hard
38. having to deal with [scale,
speed, cloud, lack of
environmental access]..
..this as of now incomplete
transition..
..is an huge opportunity for
improving security
39. the pitch (#0)
• in addition to a secure SDLC … (ie. > 1 request/
attack)
• if you’re not at this stage, work on it first
40. the pitch
• figure out what’s happening at runtime
X success
AppSensor
• make intrusion detection primitives available in app
• exploit automated response > manual response
• stop attacker before success
• get self-protecting applications and valuable intel
59. manual
@POST
public Response transfer(
String from,
String to,
String amount) {
if ( currentUser.owns(from) ) {
transfer(from, to, amount);
} else {
showErrorPage(); // normal error handling
}
return Response.ok();
}
60. manual
@POST
public Response transfer(
String from,
String to,
String amount) {
if ( currentUser.owns(from) ) {
transfer(from, to, amount);
} else {
appsensor.addEvent( new Event(currentUser, "ACE2") );
showErrorPage(); // normal error handling
}
return Response.ok();
}
61. recommendations
• Aim for key architectural choke points
• AOP can often be helpful
• Exploit custom exception hierarchies
• Look for business logic cases
• Train developers to think this way
63. appsensor-reverse-proxy
• written in go
• blocks requests
• canned detection points (toggle-able)
• easily extendable
• https://github.com/jtmelton/appsensor-
reverse-proxy
64. WAF
• Send events and/or attacks
• Receive and process responses
• OWASP CRS in ModSecurity has AppSensor
rules already
• https://www.trustwave.com/Resources/
SpiderLabs-Blog/Implementing-AppSensor-
Detection-Points-in-ModSecurity/
65. OWASP ASIDE
• secure programming IDE plugin (eclipse)
• reminder icon or highlight
• drop down list of applicable sensors
• auto-insertion of ASIDE sensor APIs and code
refactoring
• UNCC SIS project (educational component)
• https://www.owasp.org/index.php/
OWASP_ASIDE_Project
81. Rules Engine Goals
• Expand detection capabilities by providing
boolean logic and new span primitives
• Reduce false positives by leveraging several
suspicious events to discover a malicious
event
82. Rules Engine
• Multiple sensors grouped into single “Rule” to
trigger an attack
• Rule combines sensors with AND/OR/NOT/THEN
operators
• Thresholds can be lowered without increasing false-
positive rate because there are multiple indicators
• I.e. many SUSPICIOUS factors can define a
MALICIOUS factor
84. Example - Rules Engine
with AND
Sensor1 - Multiple failed login attempts
Sensor2 - Use of blacklisted characters
Sensor3 - Password attempt too long
Sensor4 - Multiple usernames attempted from single IP
Rule: Sensor1 AND Sensor2 AND Sensor3 AND Sensor4
85. Example - Rules Engine
with OR
Sensor1 - Multiple failed login attempts
Sensor2 - Use of blacklisted characters
Sensor3 - Password attempt too long
Sensor4 - Multiple users attempting to login from
single IP
Rule: Sensor1 AND (Sensor2 OR Sensor3 OR Sensor4)
86. Example - Rules Engine
with NOT
Sensor1 - Multiple failed login attempts
Sensor2 - Use of blacklisted characters
Sensor3 - Password attempt too long
Sensor4 - Multiple users attempting to login from single
IP
Sensor5 - Blacklisted IP
Rule: Sensor1 AND (Sensor2 OR Sensor3 OR Sensor4) AND
NOT Sensor5
87. Example - Rules Engine
with THEN
Sensor1 - Use of blacklisted characters
Sensor2 - Large file upload
Sensor3 - Large file download
Sensor1 THEN (Sensor2 OR Sensor3)
88. Ultimately Any Combination Will Work
Sensor1 OR Sensor2
THEN
Sensor3 AND NOT (Sensor4 OR Sensor5)
THEN
Sensor6 AND Sensor7 AND Sensor8 AND Sensor9
AND Sensor10
98. GSoC 2016 (ML)
• An external system using Logstash, Kafka
and Spark that takes in log files, runs
machine learning (ML) analysis on the
features specified by user and generates a
list of rules sorted by an evaluation
criteria.
• The aim of this system is to assist users to
identify anomalous patterns or behaviors
on their system in a readable manner.
99. ML Analysis
• Currently implemented algorithms for both simple and
complex analysis are k-means clustering, naïve bayes,
logistic regression and decision trees.
• You would need to write your own indexer for any new
categorical features if the algorithm only accepts numeric
features and your own vectorizer for different
combinations of multiple features.
• Simple analysis uses one
feature (example: HTTP
verb, response, lat/long) for
clustering and classification
• Complex analysis
takes into account
multiple features
for the ML process.
100. ML Future Work
• Project is definitely still a work in progress.
• Some changes/improvements to be made:
1. Add support for more common log file formats
2. Add support for other features that can be used in a log
file
3. Add visualization to allow users to understand results of
complex analysis better
• One major goal of current efforts is a tool you can send web
logs in standard formats and receive “suggested rules”
101. ML Docs and Video
• All documentation for the GSoC project can
be found at: https://github.com/
timothy22000/GSoC-MLAnalysisEngine
• https://youtu.be/tsdC_ftjF1g (video demo)
• Thanks Timothy Sum Hon Mun!
104. future
• analysis engines (add trend, expand rules and ML)
• expand reverse proxy
• expand appsensor-ui
• server assembler
• framework integration for detection points
(spring security exists, add others)
• your idea here ???
105. you
• help wanted!
• plenty of places to contribute and improve
• friendly, helpful community
• https://github.com/jtmelton/appsensor/issues
• https://www.owasp.org/index.php/
OWASP_AppSensor_Project#tab=Road_Map_a
nd_Getting_Involved
