Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

David J. Bianco

November 02, 2020
Tweet

More Decks by David J. Bianco

Other Decks in Technology

Transcript

  1. Incident detection & response researcher 20+ years of hands-on experience

    Specializing in: • Threat Hunting • Threat Intelligence • Detection Engineering About Me
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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?
  9. 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.
  10. 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.
  11. 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?”
  12. 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!
  13. Step 5: What Should We Do About It? Ok, we’ll

    definitely call you for this one.