$30 off During Our Annual Pro Sale. View Details »

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. Developers: What Your Security
    Team Wishes You Knew
    And It’s Not Secure Coding!
    David J. Bianco
    [email protected]
    @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
    [email protected]
    @DavidJBianco

    View Slide