How to emrace risk-based Security management in a compliance-driven culture

This lecture was presented at the IEEE ITPC at the Trenton Computer Festival on March 16.

Security and Regulatory Compliance aren’t the same thing – but they’re often confused. When you’re working in a government, healthcare, or financial environment there’s a tendency to think that if you’re FISMA-compliant or HIPAA-compliant or any other X-compliant that you must have good security.

However, sophisticated risk management and real security don’t have much to do with compliance and you can actually great security and be non-compliant with regulatory requirements as well be fully compliant but not secure. This talk, led by Security guru Shahid Shah, will talk about how make sure risk-based security management is properly incorporate into compliance-driven cultures.

Transcript

1. Do’s and Don’ts of Risk-based
   Security Management in a
   Compliance-driven Culture
   Security and Regulatory Compliance aren’t the
   same thing – but they’re often confused
   Shahid N. Shah, CEO
   

   View Slide

2. www.netspective.com 2
   NETSPECTIVE
   Who is Shahid?
   • 20+ years of architecture, design, software
   engineering, and information assurance
   (security) in embedded, desktop, and
   enterprise environments such as
   – FISMA-regulated government systems
   – HIPAA-regulated health IT systems
   – FDA-regulated medical devices and systems
   • Have held positions at CTO, Chief Architect,
   or Senior Engineer in a variety of regulated
   environments
   

   View Slide

3. Compliance vs. Security
   

   View Slide

4. NETSPECTIVE
   www.netspective.com 4
   Compliance vs. Security is like…
   Compliance
   Security
   

   View Slide

5. NETSPECTIVE
   www.netspective.com 5
   Human Resources
   Law: Compliance Order: Security
   

   View Slide

6. NETSPECTIVE
   www.netspective.com 6
   Knowledge
   Compliance knowledge bases
   FISMA PCI DSS
   HIPAA ONC
   FDA SOX
   Security knowledge areas
   Firewalls Encryption
   Access
   Control
   Pen Testing
   Continuous
   Monitoring
   Packet
   Analysis
   

   View Slide

7. NETSPECTIVE
   www.netspective.com 7
   States
   Compliance:
   Usually Binary
   Security:
   Continuous Risk Management
   

   View Slide

8. NETSPECTIVE
   www.netspective.com 8
   Reality
   You can be compliant and not secure, secure but not compliant, or both
   Both Secure
   Compliant
   

   View Slide

9. NETSPECTIVE
   www.netspective.com 9
   Compliance Requirement
   • Encrypt all data at FIPS 140
   level
   Insecure but compliant
   • Full disk encryption
   – Encryption keys stored on same
   disk
   • SSL encryption
   – No TLS negotiation or man in the
   middle monitoring
   An example of compliant insecurity
   It’s easy to check off compliance boxes and still be insecure
   Secure and compliant
   • Full disk encryption
   – Disk-independent key
   management
   • TLS encryption
   – Force SSL  TLS and monitor for
   MIM threats
   

   View Slide

10. NETSPECTIVE
    www.netspective.com 10
    Why does compliant insecurity occur?
    Compliance is focused on…
    • Regulations
    • Meetings & discussions
    • Documentation
    • Artifact completion
    checklists
    Instead of…
    • Risk management
    – Probability of attacks
    – Impact of successful attacks
    • Threat models
    – Attack surfaces
    – Attack vectors
    

    View Slide

11. Recommendations
    

    View Slide

12. NETSPECTIVE
    www.netspective.com 12
    Forget compliance
    Get your security operations
    in proper order before
    concentrating on compliance.
    Start sounding like a broken
    record, ask “is this about
    security or compliance?”
    often.
    

    View Slide

13. NETSPECTIVE
    www.netspective.com 13
    Consider costs while planning security
    100% security is impossible so compliance driven environments must be slowed by cost drivers
    Source: Olovsson 1992, “A structured approach to computer security”
    

    View Slide

14. NETSPECTIVE
    www.netspective.com 14
    Don’t rely on perimeter defense
    Firewalls and encryption aren’t enough
    

    View Slide

15. NETSPECTIVE
    www.netspective.com 15
    Classify data and assets
    Objective Purpose Low Impact Moderate
    Impact
    High Impact
    Confidentiality Protecting
    personal
    privacy and
    proprietary
    Information
    Limited adverse
    effect from
    disclosure
    Serious adverse
    effect from
    disclosure
    Catastrophic
    effect from
    disclosure
    Integrity Guarding against
    improper
    information
    modification
    or destruction
    and non-
    repudiation
    Limited adverse
    effect from
    unauthorized
    modification
    Serious adverse
    effect from
    unauthorized
    modification
    Catastrophic
    effect from
    unauthorized
    modification
    Availability Ensuring timely
    and
    reliable access to
    and use
    of information.
    Limited adverse
    effect from
    service
    disruption
    Serious adverse
    effect from
    service
    disruption
    Catastrophic
    effect from
    service
    disruption
    NIST 800-60 can help you or you can use your own system (e.g. Microsoft)
    

    View Slide

16. NETSPECTIVE
    www.netspective.com 16
    Clearly express business impacts
    Only evidence-driven business-focused impacts should be considered real threats
    

    View Slide

17. NETSPECTIVE
    www.netspective.com 17
    Define threats
    • Capability, for example:
    – Access to the system (how much privilege
    escalation must occur prior to
    actualization?)
    – Able to reverse engineer binaries
    – Able to sniff the network
    • Skill Level, for example:
    – Experienced hacker
    – Script kiddie
    – Insiders
    • Resources and Tools, for example:
    – Simple manual execution
    – Distributed bot army
    – Well-funded organization
    – Access to private information
    Motivation + Skills and Capabilities tells
    you what you’re up against and begins to
    set tone for defenses
    Create minimal documentation
    that you will keep up to date
    Create risk and threat models
    He will win who, prepared himself, waits to take the enemy unprepared – Sun Tzu
    Source: OWASP
    .org, Microsoft
    

    View Slide

18. www.netspective.com 18
    NETSPECTIVE
    Visualize attacks / vulnerabilities
    

    View Slide

19. NETSPECTIVE
    www.netspective.com 19
    Create an Attack Library
    • Password Brute Force
    • Buffer Overflow
    • Canonicalization
    • Cross-Site Scripting
    • Cryptanalysis Attack
    • Denial of Service
    • Forceful Browsing
    • Format-String Attacks
    • HTTP Replay Attacks
    • Integer Overflows
    • LDAP Injection
    • Man-in-the-Middle
    • Network Eavesdropping
    • One-Click/Session
    Riding/CSRF
    • Repudiation Attack
    • Response Splitting
    • Server-Side Code
    Injection
    • Session Hijacking
    • SQL Injection
    • XML Injection
    Source: Microsoft
    

    View Slide

20. NETSPECTIVE
    www.netspective.com 20
    Collect attack causes and mitigations
    Define the relationship
    between
    • The exploit
    • The cause
    • The fix
    SQL Injection
    Use of Dynamic
    SQL
    Use
    parameterized
    SQL
    Use stored
    procedure with
    no dynamic SQL
    Ineffective or
    missing input
    validation
    Validate input
    Source: Microsoft
    

    View Slide

21. www.netspective.com 21
    NETSPECTIVE
    How you know you’re “secure”
    • Value of assets to be protected is understood
    • Known threats, their occurrence, and how
    they will impact the business are cataloged
    • Kinds of attacks and vulnerabilities have been
    identified along with estimated costs
    • Countermeasures associated with attacks and
    vulnerabilities, along with the cost of
    mitigation, are understood
    • Real risk-based decisions drive decisions not
    security theater
    

    View Slide

22. NETSPECTIVE
    www.netspective.com 22
    Review security body of knowledge
    Everyone
    • FIPS Publication 199 (Security
    Categorization)
    • FIPS Publication 200 (Minimum
    Security Requirements)
    • NIST Special Publication 800-60
    (Security Category Mapping)
    Security ops and developers
    • NIST Special Publication 800-53
    (Recommended Security Controls)
    • Microsoft Patterns & Practices,
    Security Engineering
    • OWASP
    Executives and security ops
    • NIST Special Publication 800-18
    (Security Planning)
    • NIST Special Publication 800-30
    (Risk Management)
    Auditors
    • NIST Special Publication 800-53
    (Recommended Security Controls)
    • NIST Special Publication 800-53A Rev 1
    (Security Control Assessment)
    • NIST Special Publication 800-37
    (Certification & Accreditation)
    

    View Slide

23. www.netspective.com 23
    NETSPECTIVE
    Key Takeaway
    • If you have good security operations in place
    then meeting compliance requirements is
    easier and more straightforward.
    • Even if you have a great compliance track
    record, it doesn’t mean that you have real
    security.
    

    View Slide

24. Thank You
    Visit
    http://www.netspective.com
    http://www.healthcareguy.com
    E-mail shahid.shah@netspective.com
    Follow @ShahidNShah
    Call 202-713-5409
    

    View Slide