Developers: What Your Security Team Wishes You Knew (And It's Not Secure Coding!)

If you’re a developer, you’ve probably had your share of “secure development” training in the past. You may be familiar with the Secure Software Development Lifecycle, where you learned about the importance of threat modeling, secure coding, code reviews, testing and many other topics. These are all valuable, but most developer training leaves out an important topic: how can the developers help the security team detect and respond to incidents involving their applications?

In this session, we’ll provide developers with an inside look at the security team’s incident detection and response processes and give some easy, practical advice on things they can do while creating their apps that will make them much easier to defend.

Transcript

1. Developers: What Your Security Team Wishes You Knew And It’s Not Secure Coding! David J. Bianco DavidJBianco@gmail.com @DavidJBianco
2. Incident detection & response researcher 20+ years of hands-on experience Specializing in: • Threat Hunting • Threat Intelligence • Detection Engineering About Me
3. A Day in the Life of a SOC Analyst Analysts must quickly: • Examine an alert to understand what means • Investigate to find out if it’s an actual security concern • Act to protect the organization Rinse. Repeat ad infinitum. We need your help to make good decisions! Examine Investigate Act
4. Detection & Response Needs Visibility Context
5. Visibility: Logging Format • Human readable • Consistent structure • Labeled & documented fields Contents • Login / logout • Privilege use • Transaction details • Hosts, user IDs, etc. Coherence • Single-line logs • Multi-line logs tied together by a unique ID
6. Sample Log: ClamAV (Poor) Jul 4 17:27:51 s69819 clamd[11292]: stream: HTML.Phishing.Pay-6 FOUND Jul 4 19:01:05 s69819 clamd[11292]: stream: HTML.Phishing.Bank-490 FOUND Jul 5 12:35:44 s69819 clamd[11292]: stream: Worm.SomeFool.P FOUND Jul 5 16:42:24 s69819 clamd[11292]: stream: Exploit.HTML.IFrame FOUND Jul 5 17:23:46 s69819 clamd[11292]: stream: Worm.SomeFool.Gen-2 FOUND Jul 5 18:10:58 s69819 clamd[11292]: stream: HTML.Phishing.Pay-51 FOUND Oh no! Some fool got a worm! But which fool? Format Contents Coherence
7. Sample Log: Apache HTTPD (Adequate) 220.241.45.142 - - [17/May/2015:12:05:07 +0000] "GET /robots.txt HTTP/1.0" 200 - "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.4; http://www.majestic12.co.uk/bot.php?+)" Apache’s combined log format is consistently formatted and well documented. Once you learn how to read it, you can use it for alerting, establishing event timelines, etc. Format Contents Coherence
8. Sample Log: Zeek (Very Nice!) {"ts":1554938926.387955,"uid":"CPq5QL1ZYmbPaiewb","id.orig_h":"19 2.168.40.1","id.orig_p":63273,"id.resp_h":"192.168.40.128","id.re sp_p":80,"trans_depth":1,"method":"GET","host":"192.168.40.128"," uri":"/mutillidae/index.php?page=user- info.php&username=a&password='+or+'a'='a&user-info-php-submit- button=View+Account+Details","version":"1.1","user_agent":"python -requests/2.21.0","request_body_len":0, "response_body_len":24553,"status_code":200,"status_msg":"OK","ta gs":[],"resp_fuids":["FE8FFg2KcR7aLWOijc"],"resp_mime_types":["te xt/html"]} {"ts":1554938926.414236,"fuid":"FE8FFg2KcR7aLWOijc","tx_hosts":[" 192.168.40.128"],"rx_hosts":["192.168.40.1"],"conn_uids":["CPq5QL 1ZYmbPaiewb"],"source":"HTTP","depth":0,"analyzers":[],"mime_type ":"text/html","duration":0.0006389617919921875,"is_orig":false,"s een_bytes":24553,"total_bytes":24553,"missing_bytes":0,"overflow_ bytes":0,"timedout":false} Log files linked by unique IDs (connections/files) provide tons of context! Format Contents Coherence
9. Context: Documentation Function What does it do? Who uses it? Resources Hostnames IPs Accounts Data Storage Other? Architecture Tech stack How do the pieces fit together? External dependencies & interactions
10. How to Investigate an Alert 1. Is this real attack or a False Positive? 2. If it’s a real attack, was it successful? 3. What other resources did the attacker have access to? 4. What actions did the attacker take and when? 5. What should we do to recover and to learn from this attack?
11. Analyst Thought Process • What kind of attack is this alert about? • Are the targets vulnerable? • Host OS • Application & Tech Stack • Does the observed event look like an actual attack? • What does the target application do, and might this event be consistent with normal function? How You Can Help Documenting the purpose of the app help us distinguish between normal and malicious behavior. Step 1: Is This a False Postive? Documenting the tech stack and resources your application uses helps us understand whether the there even might be a vulnerability.
12. Step 2: Was the Attack Successful? We can usually tell, BUT… Sometimes knowledge of the application logic or transaction flow may be necessary. Don’t worry. We’ll get in touch if necessary.
13. Step 3: What Other Resources Were Involved? This is where knowledge of the application’s hosts, accounts and other resources comes in handy! If the attack is against the application itself, knowing where else to look for traces is invaluable. “Weird… That account should never log in to this system.” “Why are these two hosts talking to each other on port 8229/tcp?”
14. Step 4: What Actions did the Attacker Take? The analyst uses logs to create a timeline of events. The better your logs are, the easier (and faster) this is!
15. Step 5: What Should We Do About It? Ok, we’ll definitely call you for this one.
16. Takeaways: Please Help With… Format Contents Coherence Function Architecture Resources Used Visibility Context
17. Developers: What Your Security Team Wishes You Knew Questions? David J. Bianco DavidJBianco@gmail.com @DavidJBianco