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.
WordPress Websites for Engineers: Elevate Your Brand
How to emrace risk-based Security management in a compliance-driven culture
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
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
www.netspective.com
2
8. NETSPECTIVE
Reality
You can be compliant and not secure, secure but not compliant, or both
Compliant
www.netspective.com
Both
Secure
8
9. NETSPECTIVE
An example of compliant insecurity
It’s easy to check off compliance boxes and still be insecure
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
Secure and compliant
• Full disk encryption
– Disk-independent key
management
•
www.netspective.com
TLS encryption
– Force SSL TLS and monitor for
MIM threats
9
10. NETSPECTIVE
Why does compliant insecurity occur?
Compliance is focused on…
•
•
•
•
Regulations
Meetings & discussions
Documentation
Artifact completion
checklists
www.netspective.com
Instead of…
• Risk management
– Probability of attacks
– Impact of successful attacks
• Threat models
– Attack surfaces
– Attack vectors
10
12. NETSPECTIVE
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.
www.netspective.com
12
13. NETSPECTIVE
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”
www.netspective.com
13
14. NETSPECTIVE
Don’t rely on perimeter defense
Firewalls and encryption aren’t enough
www.netspective.com
14
15. NETSPECTIVE
Classify data and assets
NIST 800-60 can help you or you can use your own system (e.g. Microsoft)
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 nonrepudiation
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
www.netspective.com
15
16. NETSPECTIVE
Clearly express business impacts
Only evidence-driven business-focused impacts should be considered real threats
www.netspective.com
16
17. NETSPECTIVE
Create risk and threat models
He will win who, prepared himself, waits to take the enemy unprepared – Sun Tzu
Define threats
Create minimal documentation
that you will keep up to date
• 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
–
–
–
Experienced hacker
Script kiddie
Insiders
–
–
–
–
Simple manual execution
Distributed bot army
Well-funded organization
Access to private information
–
• Skill Level, for example:
• Resources and Tools, for example:
Motivation + Skills and Capabilities tells
you what you’re up against and begins to
set tone for defenses
Source: OWASP
.org, Microsoft
www.netspective.com
17
20. NETSPECTIVE
Collect attack causes and mitigations
Define the relationship
between
• The exploit
• The cause
• The fix
SQL Injection
Use of Dynamic
SQL
Use
parameterized
SQL
Ineffective or
missing input
validation
Validate input
Use stored
procedure with
no dynamic SQL
Source: Microsoft
www.netspective.com
20
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
www.netspective.com
21
22. NETSPECTIVE
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
Auditors
• NIST Special Publication 800-18
(Security Planning)
• NIST Special Publication 800-30
(Risk Management)
•
www.netspective.com
•
•
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)
22
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.
www.netspective.com
23