1. Automated Detection and Mitigation of
Application-level Asymmetric DoS Attacks
Henri Maxime Demoulin, Isaac Pedisich,
Linh Thi Xuan Phan, Boon Thau Loo
University of Pennsylvania

2. About DoS
Exhaust the victim’s resources, crash the application, delete the data
Traditionally volumetric, now increasingly low-volume and application-level attacks
Smaller footprint, not bogus at the network level

3. Limitations of current defenses
Most NIDPS, such as Snort and Bro, work with signatures and application/flow profiles to detect anomaly
But signatures are static in nature
Profiles are hard to get right
Those tools have been designed to handle large- scale network-layer attacks, and act at a coarse granularity (filter at the edge, drop at front-end proxy, etc)

4. Our approach
Fundamentally those attacks seek the same end: exhaust a given resource
Use ML to break the static nature of signatures
Learn impact of resource abuse on application components
Leverage trend toward micro-services and serverless
Design flexible per-component policies
Tightly connect execution environment and policy composition to enable autonomy and scale for the defense

5. Design GUI Local Runtime Local Runtime Operator Policy Composition
Operator labels
attack period
(various degree of
knowledge are OK)
Declare mitigation
policy templates,
request their completion
query statistics
Operator
label data
GUI
Policy Composition
Database
Trained policy
is deployed
(system statistics)
update policy
Resource
Allocation
Policy
Centralized controller
formats
and insert data in DB
Controller
Application components
are monitored at runtime
status
report
local runtimes, data monitoring
Controller pushes to database
Operator labels time periods when suspecting an attack
attack/no attack
more classes: memory attack, CPU attack, etc
Operator create a policy template, filling entity/action on her own
Policy composition engine use the labelled data to learn the predicate
Policy is deployed on the system, and enforced
deploy
Local Runtime
Local Runtime
Node 1
Node n

6. Composing mitigation policies
Template a policy with
Mitigation action
Component to defend (or flow to monitor)
Enforcement method (periodic, event-based)
Policy predicate (metrics/thresholds) will be filled with trained classifier
Cloning
HTTP parser
PERIODIC
X > ?
Isolation
All components
Y > ?

7. Learning the policy predicate
Decision Tree to learn predicate features and thresholds:
O(log n) training time where n is the number of samples
Binary and multi-class classification
Ease of interpretation

8. Feature selection Remove low-variance features
Re-weight samples to avoid class imbalance
For up to depth k, perform 10-folds cross validation
Multi-class?
Train a model per class, pick the best in a one- versus-all fashion
However this is likely to require feature engineering to capture common features

9. Use case: CPU attacks Learned isolation policy vs naive cloning policy
Cloning policy spawns new component when average queue length is greater than a fixed threshold
Isolation policy acts on flow features and temporarily segregates suspicious traffic into quarantine components

10. Isolation policy training
Workload: TLS renegotiation and ReDoS attacks
Train over flow features
A single feature could discriminate the attack !
Then we tested the policy with a yet-unseen XML attack.

11. Evaluation
Cloning spawns 24 XML components, stabilize the latency for legitimate traffic to about 100 ms
Isolation policy reacts as soon as the packet CPU time exceeds the learned threshold. Attack traffic does not interfere with legitimate traffic anymore

12. Takeways Move from static signatures and profiles to learned policies
Constrain the attack domain to the much smaller subset of resource they seek to exhaust
We were able to defend against unseen attacks
Per-component policy enables various degree of complexity for the defense
And paves the way for more advanced methods to complete and automate the policy learning

13. Next steps Evaluate other type of attacks
Make threshold learned resilient to adversarial learning
Learn other policy parameters (action, entity, etc)
Evaluate evolution of legitimate behavior

14. Questions?

15. Raw features
Label a period where we know an attack happened, with various degree of information (binary or multi-class)
Create a policy template (number of predicates, components of interest, action to execute, where to enforce it)
Query the engine
(Validate the generated policy)
Policy is deployed on the runtime

16. Runtime design Local Agent Thread Queue Updates Manager Scheduler
Component Pool
Component Pool 1 91 12 20 55 49 85 43

17. Runtime design 1 67 Runtime 1 Runtime 2 Component Pool Component Pool
Long-lived
TCP Connection
Component Pool
Component Pool
Data Queue
Data Queue 1 67
Enqueue to
next Component 12 5
Blocking thread 51
Incoming request
Outgoing response

18. Existing defenses
one rule per attack :(