Designing Secure Event-Driven Architectures - Mil-OSS

Designing Secure
Event-Driven Architectures
Richard Clayton
Chief Engineer
Road Map
• About Us
• Objectives
• Ten Considerations for Securing Event-Driven Architectures
•
•
•
•
•
•
•
•
•
•
Preliminary Research and Planning
Choose the Right Security Frameworks
Employ Redundant Security Measures
Minimize Privileges in the Architecture
Go Beyond Authentication and Authorization
Use Multidimensional Security
Scope Authorization
Secure Mixed Datasets
Secure Services
Secure Messages and Events
• Conclusion
About Us
Berico Technologies
Passionate, high-end software engineering, consulting, and
analytic services provider to the federal government.
Berico’s mission is to leverage tremendous operational
experience and the best industry talent to identify and solve our
clients’ hardest problems.
•Founded in 2006
•Presence in DC, MD, VA, FL, AZ and IZ, AF
•Best Places to Work Greater Washington: 2010,2011
•Finalist for Hottest Emerging Government Contractor
•Winner of SMARTCXO Executive Management Team
•AFCEA Meritorious Award for Engineering
Richard Clayton
Chief Engineer
Previously an Engineer, Tech Lead, and
Project Manager (2009-2011)
Tech Focus
-Service Oriented Architectures
-Event-Driven Architectures
-Distributed Computing
-Domain Modeling
Education
BS in Computer Science (Park University)
Cloudera Developer Certified
Eons Ago…
US Marine Corps (2000-2009)
SSgt / Weather Forecaster
-Certified Weather Forecaster
-Certified Weather Observer
Objectives
Help you achieve a higher-level of security
(and confidence) within your architecture by
emphasizing the lessons we have learned
during our accreditation experiences.
• Emphasize security as a first class citizen within your
domain model.
• Describe the breadth of security considerations when
designing a secure architecture.
• (Briefly) discuss the implementation of security across
distributed architectures (SOA and EDA).
Ten Considerations for Securing
Event-Driven Architectures
Preliminary Research and Planning
• Understand the scope of security requirements before
designing
Read appropriate documentation
• Determine the appropriate security goals of the system.
This should include your accreditation goals
• Consider implementing a higher security level than required.
Unplanned elevation of security requirements is common
• Get your System Administrators/Engineers involved!
• Beautiful architecture is a marriage of hardware and software
• Hardware may solve security/scalability limitations of software
• Security should be a first-class citizen in your domain model
• Preserve Pedigree and Provenance on all pieces of data.
• Consider making ACL’s a part of your object model.
Choose the Right Security Frameworks
• Don’t invent your own security framework!!!!
Unless that’s what you do for a living…
• Choose a proven, enterprise-grade technologies
• For internal networks, Kerberos and LDAP is an excellent option.
• Larger networks with greater latency are better suited by publickey encryption-based authentication technologies.
• Reuse existing infrastructure (if possible) and integrate legacy
systems.
If you have an AD instance within the organization, use it!
• Consider using Single-Sign On (SSO)
Managing 800 passwords is annoying and encourages users
have bad habits
Employ Redundant Security Measures
• Protect data in transit
Even in protected areas of the network
• Securely store data “at rest”
Encryption, redundant storage, File System and DB ACL’s
• Layer your network
Use firewalls between zones
• Restrict access in each “tier” of the application
Within the UI, at the Service Layer, at Data Sources
• Hide or obfuscate the “guts” of your application from the user
Are “power users” allowed to define there own SQL Where clauses?
• Utilize system-enforced usage policies
Group Policy is a perfect example
Minimize Privileges in the Architecture
Next to “malware”, malicious insiders are the greatest security
threat to a computer network. (Paraphrased)
http://www.networksecurityedge.com/content/top-10-information-security-threats-2010
•Reduce the rights of O&M personnel on the network
• Does everyone need to be a “Domain Admin”?
• If they do, do they need to be one all the time?
•Segregate the roles and rights of personnel on the network
Think “Checks and Balances”
•Do not reuse service accounts
Consider having one per service
•Minimize the privileges of services accounts
Few services need administrative privileges
Go Beyond Authentication and Authorization
• Auditing
• Expose application logs
• Use a consistent format (easier to extract information)
• Have an export strategy
• Use an Audit Reduction tool
• Have a multi-tiered archiving strategy
• Availability
• Employ redundancy in architecture
• Load Balancers
• Replication of File System and Storage
• Hardware/Network redundancy
• Write working code!
• Make Unit Testing and Continuous Integration apart of your design
strategy (TDD and BDD anyone?)
• Choose horizontally-scalable solutions
Go Beyond Authentication and Authorization
• Policy
• Application Policy
• Trap requests through a gateway
• Apply a rules engine against requests
• Operating System Policy
• Specify non-computer-enforceable policies in an SOP
Use Multidimensional Security
Just like Relational Databases and Object-Oriented Programming, there
is an “impedance mismatch” between DOD/IC needs and operating
system security models.
•DOD/IC security needs tend to be multidimensional (3D & 4D if
you will), and OS security models are two-dimensional.
• Operating System roles/groups describe what a user can do or
access, but not whether a user “should” given the current state of
the system.
• Real-world policy breaks this model
(e.g.: no user should be able to access dataset “A” after 6pm
unless they have their supervisor’s permission)
•Rules Engines, Complex Event Processors, and Workflow can
give you the flexibility to enforce multidimensional security
models.
Scope Authorization
• Treat every piece of information consistently
Regardless of how sensitive it is
• Determine the granularity of security within a system.
• This may be imposed based on accreditation level
• Permissions at the corpus-level.
• You should already be carrying information about the dataset on
every object within your domain model.
• Dynamically create and enforce security roles/groups for each
dataset.
• Atomic permissions per secure item.
• Every piece of information has it’s own ACL.
• Hint: This is actually easier than corpus-level security!
• Users are their own authorization scope.
Secure Mixed Datasets
Cross-corpus/classification analytics throw a wrench into most
security implementations.
•Runtime analytics
Produce cross-authorization scope in memory, per user
•Preprocessed analytics
• Create new authorization scopes based on the combined
“classification” of mixed datasets.
• Consider automatically assigning users to these new scopes as
they are created.
• Hint: Once again, this is easier to do with PL-4
(overall classification of cross-corpora datasets is the intersect of
ACL’s from each dataset)
Secure Services
• Employ Service-to-Service authentication and authorization!
• Proxy “unprotected” services by offloading authenticated
requests into protected “enclaves”
Apache HTTPD Proxy with Kerberos or Certificate Auth
• Access data as the user whenever possible
Kerberos delegation
• Use function-specific connection pools with different service
accounts for each
One service account for reads, one for writes, one for management
• Use contextual security within applications
Make assertions about user rights, and don’t be afraid to throw
exceptions!
Secure Messages and Events
• Employ Service-to-Bus, Bus-to-Bus authentication and authorization!
• Make “authorization scopes” a part of the Message/Event model.
• Who is allowed to consume an event?
• Beware of event hierarchies
• Events tend to have multidimensional security
• Who is allowed to fire an event?
• Create “mini-buses”
(conceptually channels or currents in an event stream)
• Don’t propagate events unnecessarily across buses of higher scope
• Performance burden and security risk
• Consider using encrypted envelopes.
• Use Event Stream Processors and Complex Event Processors to
monitor service behavior. Record abnormal activity.
Conclusion
Recap
• About Us
• Objectives
• Ten Considerations for Securing Event-Driven Architectures
•
•
•
•
•
•
•
•
•
•
Preliminary Research and Planning
Choose the Right Security Frameworks
Employ Redundant Security Measures
Minimize Privileges in the Architecture
Go Beyond Authentication and Authorization
Use Multidimensional Security
Scope Authorization
Secure Mixed Datasets
Secure Services
Secure Messages and Events
Contact Us.
Questions?
Berico Technologies, LLC
1501 Lee Hwy Suite 303
Arlington, VA 22209
(o) 703.224.8300
www.bericotechnologies.com
Guy Filipelli, CEO
guy@bericotechnologies.com
Richard Clayton, Chief Engineer
richard@bericotechnologies.com
www.gettingcirrius.com
We want you!
recruiting@bericotechnologies.com