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
   

   View Slide

2. Incident detection &
   response researcher
   20+ years of hands-on
   experience
   Specializing in:
   • Threat Hunting
   • Threat Intelligence
   • Detection Engineering
   About Me
   

   View Slide

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
   

   View Slide

4. Detection & Response Needs
   Visibility Context
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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?
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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?”
    

    View Slide

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!
    

    View Slide

15. Step 5: What Should We Do About It?
    Ok, we’ll definitely call you for this one.
    

    View Slide

16. Takeaways: Please Help With…
    Format
    Contents
    Coherence
    Function
    Architecture
    Resources
    Used
    Visibility Context
    

    View Slide

17. Developers: What Your Security
    Team Wishes You Knew
    Questions?
    David J. Bianco
    DavidJBianco@gmail.com
    @DavidJBianco
    

    View Slide