Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Compliance vs. Security

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Recommendations

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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”

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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)

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

www.netspective.com 18 NETSPECTIVE Visualize attacks / vulnerabilities

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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)

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

Thank You Visit http://www.netspective.com http://www.healthcareguy.com E-mail [email protected] Follow @ShahidNShah Call 202-713-5409